在unix和linux下(也可能在OSX下),當(dāng)前的文件系統(tǒng)編碼由LC_CTYPE
區(qū)域設(shè)置參數(shù)(參見函數(shù))setlocale()
)。例如,它可能評估如下en_US.UTF-8
這意味著編碼是UTF-8。然后,可以用以下方法創(chuàng)建文件名及其路徑:fopen()
或被dir()
用這個編碼。
在Windows下,PHP作為“非Unicode感知程序”運行,然后文件名從文件系統(tǒng)使用的UTF-16(Windows 2000及更高版本)來回轉(zhuǎn)換到選定的“代碼頁”??丶姘濉皡^(qū)域和語言選項”、選項卡面板“格式”設(shè)置由LC_CTYPE
選項,而“非Unicode程序的管理->語言”則設(shè)置文件名的翻譯代碼頁。在西方國家LC_CTYPE
參數(shù)的計算結(jié)果如下language_country.1252
其中1252是代碼頁,也稱為“Windows1252編碼”,與ISO-8859-1類似(但不完全相同)。在日本,932代碼頁通常被設(shè)置為其他國家,以此類推。在PHP下,您可以創(chuàng)建名稱可以用當(dāng)前代碼頁表示的文件。反之亦然,從文件系統(tǒng)檢索的文件名和路徑將使用“最佳匹配”當(dāng)前代碼頁.
這種映射是近似的,因此某些字符可能會以不可預(yù)知的方式損壞。例如,Caffé Brillì.txt
將由dir()
作為PHP字符串Caff\xE9 Brill\xEC.txt
與預(yù)期一樣,如果當(dāng)前代碼頁為1252,則返回近似Caffe Brilli.txt
在日本系統(tǒng)中,因為重音元音在932代碼頁中丟失,然后被它們的“最佳匹配”非重音元音所取代。無法翻譯的字符被檢索為?
(問號)。一般來說,在Windows下,沒有安全的方法來檢測這些工件。
更多詳情,請參閱我對PHPbug編號47096.