2

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

4

1 回答 1

3 
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 是 little-endian 与操作系统无关），但显然它有，因为你得到的值都是颠倒字节顺序的结果.

最好明确说明两个字节顺序，并避免使用 BOM。UCS-4LE用作编码，并使用V*. 也是如此unicode_code_to_utf8。

也请忽略清单 6。省略号字符（如 fi-ligature 和其他字符）是我们不会在现代 Unicode 和 OpenType 世界中使用的“兼容字符”。由字体决定是否提供上下文替代方案，fi或者...如果它愿意，而不是要求我们修改文本。

于 2010-10-04T12:28:26.100 回答