Tynambule

Aah, l’encodage… Depuis que j’ai appris que tout n’était pas en ISO-8859-1, j’ai l’impression que tous les caractères des douzes coins du monde luttent contre ma pauvre et innocente personne. Et même la (louable) tentative de l’Unicode de passer un bon coup de balais dans tout ce bordel ne m’a à vrai dire pas réellement facilité la tâche.

Mais le pire… C’est Microsoft.

Entre le support « vite fait » de l’entête BOM (Byte Order Mark, jusqu’à peu je pensais que c’était un bug. ), l’Unicode « mais pas tout » de la plupart des logiciels, l’UTF-8, l’UTF-16, les fichiers de douze gigatonnes de plus que leur équivalent ASCII, … Bref, j’ai parfois l’impression que l’Unicode n’a fait que se noyer au milieu des millions d’autres encodages propriétaires ou non, plutôt que de tous les dominer et de devenir un standard mondial.

La principale faille de PHP réside d’ailleurs dans l’absence de gestion native de l’Unicode. Résultat, on est dépendant de la plate-forme sur laquelle tourne le serveur. J’ai un collègue qui bosse sur un Windows XP japonais, la moitié des scripts « encodage-sensitive » se petent la gueule chez lui à moins de feinter pour le développement.

Mais le pire, le pire… C’est l’encodage semi-propriétaire. L’exemple le plus tragiquement mortel réside dans l’ISO-8859-1 (aussi appellé Latin truc, parce que c’était pas assez chiant sinon), au niveau de la plage 0×80-0x9F (128-159). Ces caractères ne sont *pas* définis par la norme ISO. C’était une erreur… Ils auraient du mettre n’importe quoi, des petits lapins en police, des points d’interrogation, des bananes en string, mais surtout ne pas les laisser vide… Car aussitôt, Microsoft a eut la bonne idée de se dire « Rajoutons des caractères propriétaires là dedans! ». Ah, mais pas partout (ce fut trop simple). Ah, et aussi des caractères important (genre le « é »), histoire que les gens ne puissent pas ne pas en tenir compte. Ah, et quand on se fait taper parce qu’une norme n’est pas faite pour être modifiée… On ne revient pas en arrière, on décrète un nouvel encodage, le diabolique Windows-1252.

Dans mes pérégrinations avec des XML à encodage unique et particulier, je me suis retrouvé à devoir traiter des données ayant Microsoft Office pour origine. Bon, je ne m’attendais pas à ce que ce soit particulièrement agréable, ayant déjà été en contact avec les caractères noséabonds pondus par Word, mais je ne m’attendais pas à ce que ce soit si chiant. Entre les « é » qui disparaissent dans les lymbes, les apostrophes encodées sur 2 bits (parce que l’originale était pas assez penchée vers la gauche), … L’enfer.

Voici une petite fonction PHP, venue d’un commentaire de la doc’, qui permet de nettoyer les caractères de mer.. Heum. Spéciaux de l’encodage Windows-1252 pour en faire du Latin 15.

1
2
3
4
5
6
7
8

function demicrosoftize($str) {
return strtr($str,
"\x82\x83\x84\x85\x86\x87\x89\x8a" .
"\x8b\x8c\x8e\x91\x92\x93\x94\x95" .
"\x96\x97\x98\x99\x9a\x9b\x9c\x9e\x9f",
"'f\".**^\xa6<\xbc\xb4''" .
"\"\"---~ \xa8>\xbd\xb8\xbe");
}

Je persiste à dire que l’encodage en hiéroglyphes des égyptiens était moins chiant… Allez, salut.