PHP et Unicode: Weirdness entre Windows et Linux

Question

Regardez IBM Unicode for the working PHP programmer, en particulier les annonces 3 et 4.

Sur Ubuntu Lucid je reçois la même sortie à partir du code tout comme IBM, à savoir:

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

Cependant, sur Windows, j'obtiens une réponse complètement différente.

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

Mis à part le fait que les caractères russes (qui sont en UTF-32) ne rendent pas dans un shell cmd.exe (parce qu'ils sont en UTF-32 ne propre UTF-16 de Windows) , pourquoi les valeurs de caractères diffèrent-elles si significativement?

Answer 1

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

Cela fait deux choses mauvaises:

1. Il utilise « UTF-32 », qui passera une nomenclature indésirable au début de la chaîne, qui est la raison pour laquelle vous obtenez 65279 (0xFEFF nomenclature). Vous ne voulez pas que des nomenclatures errantes traînent autour de l'endroit causant des ennuis.

2. Il utilise l'octet spécifique à la machine (capital L) avec lequel iconv peut ne pas correspondre. Pour être honnête, je n'aurais pas attendu pour se heurter sur une boîte Windows (comme i386 est little-endian quel que soit le système d'exploitation), mais il est clair que, comme les valeurs que vous avez sont tout ce qui résulterait d'un inversé ordre des octets.

Il est préférable d'indiquer explicitement les deux ordres d'octets et d'éviter la nomenclature. Utilisez UCS-4LE comme codage et décompressez avec V*. La même chose vaut pour unicode_code_to_utf8. Ignorer également la liste 6. Le caractère elliptique - comme la fi ligature et autres - est un «caractère de compatibilité» que nous n'utiliserions pas dans le monde moderne Unicode-et-OpenType. C'est à la police de fournir des alternatives contextuelles pour fi ou ... si elle le souhaite, au lieu de nous demander de modifier le texte.