On ne le croirait pas \u00e0 priori mais le traitement des caract\u00e8res par l’ordinateur est devenu un sujet complexe. Pour comprendre, commen\u00e7ons par un peu d’histoire.<\/p>\n
Les ordinateurs ne comprennent que les nombres. Pour leur permettre de traiter les caract\u00e8res, il a fallu associer un nombre \u00e0 chaque caract\u00e8re. Il y a eu quelques tentatives (codes de 5 bits, de 7 bits, de 8 bits, de 9 bits, etc). 2 codes ont surv\u00e9cu \u00e0 cette premi\u00e8re \u00e9poque; ce sont l’ASCII (code de 7 bits) et l’EBCDIC (code de 8 bits, principalement utilis\u00e9 par IBM). Le texte qui suit ne traitera pas de l’EBCDIC.<\/p>\n
N’ayant que 7 bits, l’ASCII ne permet que 128 combinaisons. Il inclut 32 codes de contr\u00f4le, 52 caract\u00e8res alphab\u00e9tiques (majuscules et minuscules), 10 chiffres et des caract\u00e8res de ponctuation. \u00c9tant d’origine \u00e9tats-unienne, ce code ne laissait aucune place aux caract\u00e8res particuliers des autres langages. C’\u00e9tait frustrant.<\/p>\n
Puis vint le PC (circa 1981). IBM\u00a0 introduit les codepage<\/em>. Ce sont des codes de 8 bits o\u00f9 les 128 premiers sont ceux de l’ASCII et les 128 autres sont disponibles pour les autres alphabets. Des compromis \u00e9taient n\u00e9cessaires puisque 256 combinaisons ne sont pas suffisantes pour tous les caract\u00e8res internationaux. Plus d’une centaine de codepage<\/em> ont \u00e9t\u00e9 cr\u00e9\u00e9s, tr\u00e8s souvent incompatibles. Par exemple, le \u00e9 avait la valeur 130 dans le CP437, 233 dans le CP1252 et 142 dans le Mac-Roman de Apple. Il fallait choisir le codepage<\/em> en fonction de l’ensemble des caract\u00e8res \u00e0 utiliser.<\/p>\n C’\u00e9tait la pagaille.<\/p>\n Vers 1978, Xerox proposa de cr\u00e9er un jeu de caract\u00e8res universel qui portera plus tard le nom d’Unicode. La 1\u00e8re version arriva vers 2004 et nous en sommes aujourd’hui \u00e0 sa 10i\u00e8me version. Unicode (aussi connu sous le nom de ISO-10646), contient maintenant 136,755 caract\u00e8res et symboles. Le probl\u00e8me est qu’il faut au moins 3 octets pour repr\u00e9senter autant de combinaisons. C’\u00e9tait trop!<\/p>\n L’UTF fut d\u00e9velopp\u00e9 pour compresser Unicode. Le principe fondamental d’UTF est que les caract\u00e8res les plus communs se repr\u00e9sentent avec un seul octet et que les autres caract\u00e8res sont repr\u00e9sent\u00e9s par 2, 3 ou 4 octets.<\/p>\n Plusieurs versions d UTF ont \u00e9t\u00e9 d\u00e9velopp\u00e9es:<\/p>\n Est-ce qu’Unicode solutionne tous les probl\u00e8mes. Pas vraiment!<\/p>\n D\u00e9tecter quel encodage est utilis\u00e9 dans un fichier n’est pas \u00e9vident et plusieurs algorithmes ont \u00e9t\u00e9 d\u00e9velopp\u00e9s pour ce faire.\u00a0 Mais aucun n’est parfait.<\/p>\n Linux fournit quelques outils pour faire ce travail:<\/p>\n listera toutes les lignes du fichier qui contiennent un encodage invalide en UTF-8.<\/p>\n Note1: S’il y a une empreinte en d\u00e9but de fichier, UTF-16 devient UTF-16BE (big-endian<\/em>) ou UTF-16LE (little-endian<\/em>)<\/p>\n R\u00e9f\u00e9rences<\/p>\n\n
\n
\n
file fichier8\r\nfichier8: UTF-8 Unicode text<\/pre>\n
\n
iconv -f utf8 fichier8 > \/dev\/null ;; echo OUIOUI\r\nif iconv -f utf16 fichier8 >\/dev\/null 2>&1; then echo OUI; else echo NON; fi\r\nNON<\/pre>\n
\n
grep -avx\u00a0 '.*'\u00a0 fichier<\/pre>\n