查看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); }
这有两件事是错误的：
它使用“UTF-32”，这将在字符串的开头删除不需要的BOM，这就是为什么你得到65279（0xFEFF BOM）。 你不希望在这个地方挂着流浪的BOM造成麻烦。
它使用iconv可能不会同意的特定于机器的字节序列（大写字母L ）。 说实话，我不会期望它会冲突在一个Windows的盒子（因为i386是小端，不管操作系统），但显然它已经，因为你已经得到的价值是什么会导致一个颠倒的字节顺序。
最好明确说明两个字节排序，并避免BOM。 使用UCS-4LE作为编码，并用V*解压缩。 unicode_code_to_utf8 。
同样忽略清单6.省略号字符（如fi-ligature和其他字符）是一种“兼容性字符”，我们不会在现代的Unicode和OpenType世界中使用。 这是由字体提供上下文替代fi或...如果它想，而不是要求我们破坏文本。