PHP和Unicode:Windows和Linux之间的古怪

查看IBM的Unicode编程器 ,尤其是清单3和清单4。

在Ubuntu Lucid上,我得到了与IBM相同的代码输出,即:

Здравсствуйте Array ( [1] => 65279 [2] => 1047 [3] => 1076 [4] => 1088 [5] => 1072 [6] => 1074 [7] => 1089 [8] => 1089 [9] => 1090 [10] => 1074 [11] => 1091 [12] => 1081 [13] => 1090 [14] => 1077 ) Здравсствуйте 

但是,在Windows上,我得到了完全不同的回应。

 ðùð┤ÐÇð░ð▓ÐüÐüÐéð▓Ðâð╣ÐéðÁ Array ( [1] => -131072 [2] => 386138112 [3] => 872677376 [4] => 1074003968 [5] => 805568512 [6] => 839122944 [7] => 1090781184 [8] => 1090781184 [9] => 1107558400 [10] => 839122944 [11] => 1124335616 [12] => 956563456 [13] => 1107558400 [14] => 889454592 ) ðùð┤ÐÇð░ð▓ÐüÐüÐéð▓Ðâð╣ÐéðÁ 

除了俄文字符(使用UTF-32格式)不能在CMD.EXEshell中显示(因为它们是UTF-32而不是Windows自己的UTF-16),为什么字符值不同如此显着?

 function utf8_to_unicode_code($utf8_string) { $expanded = iconv("UTF-8", "UTF-32", $utf8_string); return unpack("L*", $expanded); } 

这有两件事是错误的:

  1. 它使用“UTF-32”,这将在字符串的开头删除不需要的BOM,这就是为什么你得到65279(0xFEFF BOM)。 你不希望在这个地方挂着流浪的BOM造成麻烦。

  2. 它使用iconv可能不会同意的特定于机器的字节序列(大写字母L )。 说实话,我不会期望它会冲突在一个Windows的盒子(因为i386是小端,不管操作系统),但显然它已经,因为你已经得到的价值是什么会导致一个颠倒的字节顺序。

最好明确说明两个字节排序,并避免BOM。 使用UCS-4LE作为编码,并用V*解压缩。 unicode_code_to_utf8

同样忽略清单6.省略号字符(如fi-ligature和其他字符)是一种“兼容性字符”,我们不会在现代的Unicode和OpenType世界中使用。 这是由字体提供上下文替代fi...如果它想,而不是要求我们破坏文本。