Bug #77711 [Com]: CURLFile unable to handle UNICODE filenames
| From: | anrdaemon at freemail dot ru | 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