代码之家  ›  专栏  ›  技术社区  ›  bugmagnet

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

  •  2
  • bugmagnet  · 技术社区  · 14 年前

    看看IBM的 Unicode for the working PHP programmer ,尤其是清单3和4。

    Здравсствуйте
    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
    )
    Здравсствуйте
    

    ðùð┤ÐÇð░ð▓ÐüÐüÐéð▓Ðâð╣ÐéðÁ
    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中)不在命令行shell(因为它们在UTF-32而不是Windows自己的UTF-16中),为什么字符值差别如此显著?

    1 回复  |  直到 14 年前
        1
  •  3
  •   bobince    14 年前
    function utf8_to_unicode_code($utf8_string)
    {
        $expanded = iconv("UTF-8", "UTF-32", $utf8_string);
        return unpack("L*", $expanded);
    }
    

    这有两个错误:

    1. 它使用特定于机器的字节结尾(大写) L iconv 很可能不同意。老实说我不会的 预期

    最好显式地声明这两个字节顺序,并避免使用BOM。使用 UCS-4LE 作为编码,并用 V* . 同样的道理 unicode_code_to_utf8

    同样忽略清单6。像fi连字之类的省略号字符是一个兼容字符,在现代Unicode和OpenType世界中我们不会使用它。它的字体提供上下文的替代品 fi ... 如果它想,而不是要求我们把文本弄糟。