Edit report at http://bugs.php.net/bug.php?id=54028&edit=1
ID: 54028
Comment by: carsten_sttgt at gmx dot de
Reported by: schmale at froglogic dot com
Summary: Directory::read() cannot handle non-unicode chars
properly
Status: Bogus
Type: Bug
Package: Directory function related
Operating System: Windows 7
PHP Version: 5.3.5
Block user comment: N
Private report: N
New Comment:
> How can "mb_detect_encoding($content)" returing 'UTF-8'
Ok, with strict encoding detection it's working as aspected.
@schmale
> The expected result, of course, was that the return value of read is
always
> encoded in UTF-8, i.e. no messages are print, when we run the script.
The return value for filesystem functions in PHP should be "CP1252" on
most systems (Western European). It's just e.g. 'abc' in CP1252 is also
a valid UTF-8 string. But a CP1252 'ü' is not a valid UTF-8 'ü'.
And of course, with PHP, you have problems accessing files with
filenames outside CP1252 (even you can see them in explorer with the
correct names). (you can use the COM extension to manage such files)
Previous Comments:
------------------------------------------------------------------------
[2011-02-25 15:39:17] carsten_sttgt at gmx dot de
> There is no bug but a feature request for Unicode support.
You are right. It's not a Unicode (or ANSI) issue/bug.
"%USERPROFILE%\Startmenü" is a link to
"%APPDATA%\Microsoft\Windows\Start Menu"
| mklink /j "%USERPROFILE%\Startmenü"
"%APPDATA%\Microsoft\Windows\Start Menu"
and tsrm_realpath seems to have a problem with this. eg. the same with
getcwd() is working.
But back to the first question:
How can
"mb_detect_encoding($content)" returing 'UTF-8'
and
"mb_check_encoding($content, 'UTF-8')" returning FALSE for the same
$content?
------------------------------------------------------------------------
[2011-02-25 15:23:24] paj...@php.net
Sorry, but I don't have any more ways to explain why it could work for
one case or
another. There is no bug but a feature request for Unicode support.
------------------------------------------------------------------------
[2011-02-25 14:16:37] carsten_sttgt at gmx dot de
> PHP relies on the ANSI APIs and the encoding is then the runtime
encoding
> (whatever is set for the running process or system wild).
"Startmenü" can be accessed without any problems thought the ANSI API.
An "ü" exists in CP437, CP850 and CP1252 (just use the chcp command),
thus I'm not talking about unicode. You can also test this with a small
C-Code. So why is
| php -r "echo realpath('.');"
returning false?
------------------------------------------------------------------------
[2011-02-25 13:56:58] paj...@php.net
I'm not sure what else I should say to explain what is possible and what
not.
Last attempt: Unless you 100% know which runtime encoding is actually
used by
the process where PHP runs, you are are out of luck and have to use
ASCII (if
you have luck, maybe ANSI too).
But anything related to Unicode does not work, period. Even if one can
have the
feeling that it works from time to time due to the joy of similar
encoding, or
close enough.
------------------------------------------------------------------------
[2011-02-25 13:52:29] carsten_sttgt at gmx dot de
> Windows supports UCS-2 internally via the wild char APIs.
I now... I'm just wondering why:
"mb_detect_encoding($content)" is returing 'UTF-8'
and
"mb_check_encoding($content, 'UTF-8')" is returning FALSE?
Also I think there is another problem:
| C:\Users\Carsten Wiedmann>php -r "echo realpath('.');"
| C:\Users\Carsten Wiedmann
| C:\Users\Carsten Wiedmann>cd Startmenü
|
| C:\Users\Carsten Wiedmann\Startmenü>php -r "echo realpath('.');"
|
| C:\Users\Carsten Wiedmann\Startmenü>
Regards,
Carsten
------------------------------------------------------------------------
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
http://bugs.php.net/bug.php?id=54028
--
Edit this bug report at http://bugs.php.net/bug.php?id=54028&edit=1
