I can\'t use mkdir
to create folders with UTF-8 characters:
when I
Under Unix and Linux (and possibly under OS X too), the current file system encoding is given by the LC_CTYPE
locale parameter (see function setlocale()
). For example, it may evaluate to something like en_US.UTF-8
that means the encoding is UTF-8. Then file names and their paths can be created with fopen()
or retrieved by dir()
with this encoding.
Under Windows, PHP operates as a "non-Unicode aware program", then file names are converted back and forth from the UTF-16 used by the file system (Windows 2000 and later) to the selected "code page". The control panel "Regional and Language Options", tab panel "Formats" sets the code page retrieved by the LC_CTYPE
option, while the "Administrative -> Language for non-Unicode Programs" sets the translation code page for file names. In western countries the LC_CTYPE
parameter evaluates to something like language_country.1252
where 1252 is the code page, also known as "Windows-1252 encoding" which is similar (but not exactly equal) to ISO-8859-1. In Japan the 932 code page is usually set instead, and so on for other countries. Under PHP you may create files whose name can be expressed with the current code page. Vice-versa, file names and paths retrieved from the file system are converted from UTF-16 to bytes using the "best-fit" current code page.
This mapping is approximated, so some characters might be mangled in an unpredictable way. For example, Caffé Brillì.txt
would be returned by dir()
as the PHP string Caff\xE9 Brill\xEC.txt
as expected if the current code page is 1252, while it would return the approximate Caffe Brilli.txt
on a Japanese system because accented vowels are missing from the 932 code page and then replaced with their "best-fit" non-accented vowels. Characters that cannot be translated at all are retrieved as ?
(question mark). In general, under Windows there is no safe way to detect such artifacts.
More details are available in my reply to the PHP bug no. 47096.