Bug #77711 [Com]: CURLFile unable to handle UNICODE filenames

From: Date: Tue, 12 Mar 2019 00:21:33 +0000
Subject: Bug #77711 [Com]: CURLFile unable to handle UNICODE filenames
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-219918@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77711&edit=1 ID: 77711 Comment by: anrdaemon at freemail dot ru Reported by: anrdaemon at freemail dot ru Summary: CURLFile unable to handle UNICODE filenames Status: Assigned Type: Bug Package: cURL related Operating System: Windows PHP Version: 7.3.3 Assigned To: ab Block user comment: N Private report: N New Comment: If you ask me, since PHP does filenames' charset conversion by itself (Win32 API does not support UTF-8 to the best of my knowledge), the solution should likely fall to cURL ext. Previous Comments: ------------------------------------------------------------------------ [2019-03-11 23:06:20] kalle@php.net @Anatol, can you confirm my theory? Daniel said on Twitter that he did not have the time to look into this issue, but told us to report it upstream if its an actual cURL issue ------------------------------------------------------------------------ [2019-03-11 22:55:29] kalle@php.net From a quick read, it seems like the issue is caused in cURL itself, as internally we pass the filename supplied directly to curl_formadd(). I see two ways we can fix this: 1) Upstream fix from cURL 2) Implement a file name normalization fix for Windows, however I do not know how this will affect cURL Assigning this to Daniel, perhaps he can share some insights on this. ------------------------------------------------------------------------ [2019-03-08 16:00:31] anrdaemon at freemail dot ru Description: ------------ CURLFile starting from PHP 7.1 is unable to handle local paths containing UNICODE sequences. The workaround is to iconv() the path to single-byte character set used by WinAPI non-widestring family of functions on a given OS installation. But that's limiting the usability of the language to laughable levels. $ php -i | grep -E "chars|encod" default_charset => CP866 => CP866 input_encoding => CP866 => CP866 internal_encoding => UTF-8 => UTF-8 output_encoding => CP866 => CP866 zend.script_encoding => no value => no value exif.encode_jis => no value => no value exif.encode_unicode => ISO-8859-15 => ISO-8859-15 iconv.input_encoding => no value => no value iconv.internal_encoding => no value => no value iconv.output_encoding => no value => no value mailparse.def_charset => UTF-8 => UTF-8 HTTP input encoding translation => disabled mbstring.encoding_translation => Off => Off mbstring.internal_encoding => no value => no value Test script: --------------- <?php // Cyrillic capital letter A // tempnam() returns path encoded in internal_encoding $name = tempnam(__DIR__, "\u{0410}"); //print bin2hex(basename($name)); file_put_contents($name, "Test."); $file = new \CURLFile($name, null, "file"); // $file = new \CURLFile(iconv("UTF-8", "CP1251", $name), null, "file"); // Rather arbitrary workaround $curl = curl_init($argv[1] ?: "http://example.org/post.php"); curl_setopt_array($curl, [ CURLOPT_POST => true, CURLOPT_POSTFIELDS => [ "file" => $file, ], CURLOPT_VERBOSE => true, ]); $rc = curl_exec($curl); if($rc === false) { $err = curl_errno($curl); error_log(curl_strerror($err) . " ($err): " . curl_error($curl)); die; } print "$rc"; Expected result: ---------------- Successful upload. Actual result: -------------- Failed to open/read local data from file/application (26): ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=77711&edit=1

« previous php.bugs (#219918) next »