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 回答