PHP und Unicode: Verrücktheit zwischen Windows und Linux

Question

Schauen Sie sich IBMs Unicode für die Arbeit PHP-Programmierer , insbesondere Listings 3 und 4

Auf Ubuntu Lucid ich die gleiche Ausgabe aus dem Code erhalten, wie IBM tut, nämlich:

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

Allerdings unter Windows bekomme ich eine ganz andere Antwort.

ðùð┤ÐÇð░ð▓ÐüÐüÐéð▓Ðâð╣ÐéðÁ
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
)
ðùð┤ÐÇð░ð▓ÐüÐüÐéð▓Ðâð╣ÐéðÁ

Abgesehen von der Tatsache, dass die russischen Zeichen (die in UTF-32) sind Sie machen nicht in einem cmd.exe-Shell (weil sie in UTF-32 sind nicht Windows-eigene UTF-16), warum das tun Zeichenwerte unterscheiden sich so deutlich?

Answer 1

function utf8_to_unicode_code($utf8_string)
{
    $expanded = iconv("UTF-8", "UTF-32", $utf8_string);
    return unpack("L*", $expanded);
}

Das macht zwei Dinge falsch:

1. Es verwendet „UTF-32“, die zu Beginn der Zeichenfolge eine unerwünschte BOM fallen wird, weshalb Sie 65279 (0xFEFF BOM) erhalten. Sie wollen nicht, Streustücklisten um hängen die Stelle Probleme verursacht.

2. Es verwendet maschinenspezifische Byte endianness (capital L), die iconv kann auch nicht zustimmen. Um ehrlich zu sein, habe ich nicht erwartet es auf einem Windows-kollidieren (wie i386 ist Little-Endian unabhängig von OS), aber klar ist es, da die Werte, die Sie haben alle was führen würde aus umgekehrter Byte-Reihenfolge.

Besser beiden Byte Anordnungen ausdrücklich darauf hinweisen, und die Stückliste vermeiden. Verwendung UCS-4LE wie die Kodierung und auspacken mit V*. Das gleiche gilt für unicode_code_to_utf8.

Auch ignore Liste 6. Die Auslassungszeichen wie die fi-Ligatur und andere-ein ‚Kompatibilität Charakter‘, die wir nicht in der modernen Unicode-und-Opentype-Welt verwenden würden. Es liegt an die Schrift kontextuelle Alternativen für fi oder ... zu bieten, wenn es will, statt uns zu verlangen, um den Text zerfleischen.