PHP 和 Unicode：Windows 和 Linux 之间的奇怪之处

Question

看看IBM的 适合 PHP 程序员的 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.EXE shell 中呈现（因为它们采用 UTF-32 格式而不是 Windows 自己的 UTF-16 格式）这一事实之外，为什么字符值不同如此显着？

Answer 1

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. 它使用机器特定的字节字节顺序（大写 L） 哪个 iconv 很可能不同意。说实话我不会 预期的 它会在 Windows 机器上发生冲突（因为无论操作系统如何，i386 都是小端字节序），但显然它会发生冲突，因为您获得的值都是反向字节顺序产生的结果。

最好明确地说明两个字节顺序，并避免使用 BOM。使用 UCS-4LE 作为编码，并解压 V*. 。同样适用于 unicode_code_to_utf8.

也忽略清单 6。省略号字符（如连字和其他字符）是一种“兼容字符”，我们不会在现代 Unicode 和 OpenType 世界中使用它。由字体来提供上下文替代 fi 或者 ... 如果它愿意，而不是要求我们破坏文本。