Bug->Req #77711 [Wfx->ReO]: CURLFile should support UNICODE filenames
| From: | cmb@php.net | Date: | Mon, 15 Apr 2019 17:17:42 +0000 |
| Subject: | Bug->Req #77711 [Wfx->ReO]: CURLFile should support UNICODE filenames | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-220469@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
Updated by: cmb@php.net
Reported by: anrdaemon at freemail dot ru
-Summary: CURLFile unable to handle UNICODE filenames
+Summary: CURLFile should support UNICODE filenames
-Status: Wont fix
+Status: Re-Opened
-Type: Bug
+Type: Feature/Change Request
Package: cURL related
Operating System: Windows
PHP Version: 7.3.3
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Re-opening as feature request, since it is doable with the
curl_mime_*() API[1].
[1] <https://github.com/php/php-src/pull/4032>
Previous Comments:
------------------------------------------------------------------------
[2019-03-15 13:56:50] anrdaemon at freemail dot ru
One of the libcurl developers expressed a concern[1] regarding API used by extension.
As I'm not a C/C++ guy myself, I'd like to invite interested parties to join the dicussion
on github.
[1] https://github.com/curl/curl/issues/3675#issuecomment-473191793
------------------------------------------------------------------------
[2019-03-13 21:13:00] anrdaemon at freemail dot ru
Yes, filed it as https://github.com/curl/curl/issues/3675
------------------------------------------------------------------------
[2019-03-13 09:27:07] kalle@php.net
Thanks a lot Anatol for your detailed description, I personally like option 3 (which is similar to
parts of libgd), but this is now all in cURL's hands and I don't think we should engineer
a fix that could be potentially incompatible, but instead hope it can and will be fixed in cURL.
@anrdaemon If you report it upstream to cURL, then please link to this ticket. I will mark it as a
"Won't Fix".
Thank you!
------------------------------------------------------------------------
[2019-03-12 20:46:06] anrdaemon at freemail dot ru
Understood, thanks for looking into the issue.
I'll bring it up with cURL, if you don't mind.
------------------------------------------------------------------------
[2019-03-12 11:04:17] ab@php.net
It functionality in the description has been never present in PHP in the claimed form. libcurl still
uses ANSI APIs which causes reports like https://github.com/curl/curl/issues/345. A
solution needs to be done on the side cURL to
- always handle filenames as UTF-8, use Unicode APIs internally and do conversion, or
- export additional APIs based on wide chars, or
- export handlers for I/O operations, that can be overridden
The first option could be the easiest, but it would be a huge BC breach.
The second option might be more compatible, but it might lead to duplicating a lot of APIs.
The third option would regard to fopen, stat and several other I/O APIs involving filenames. Then
any consuming library could make this part of cURL compatible to its needs. Perhaps that would be
the cleanest way.
cURL could be also compiled with UNICODE, but i'm not sure it would really work. Fe see places
like this https://github.com/curl/curl/blob/f762fec323f36fd7da7ad6eddfbbae940ec3229e/src/tool_filetime.c#L40
where ANSI function is used directly so would stay same even with UNICODE. And in any case PHP
can't be compiled with UNICODE, so that's not an option.
@anrdaemon what merely has changed is, that you don't pass the filename in the ANSI codepage
anymore, so the commented out iconv fix brings it to the correct state.
Thanks.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=77711
--
Edit this bug report at https://bugs.php.net/bug.php?id=77711&edit=1