Mysql et PHP : Les jeux de caractères (interclassement)

Les jeux de caractères

Si vous voulez comprendre quelque chose à ce tutoriel, il faut absolument que vous maîtrisiez la notion de jeu de caractères. Si vous savez déjà de quoi il s'agit, vous pouvez passer directement à la section suivante. Sinon, lisez ce qui suit.

L'ordinateur ne connaît pas la notion de caractères à proprement parler
; il ne connaît que les nombres. Du coup, on a inventé une table de
conversion qui fait correspondre un nombre à un caractère : il s'agit
de l'ASCII. Ce dernier définit 128 caractères, sur 7 bits.

Cela fonctionnait très bien lorsque l'informatique n'était encore qu'à
ses débuts. Mais ensuite, on s'est rendu compte qu'on avait oublié dans
ce code d'inclure... les caractères accentués de nos chères langues
nationales. Ainsi, il était impossible d'écrire un "é", un "è", un "à"
ou un "ù", et encore moins des glyphes arabes, chinois ou japonais.

Pour remédier à cela, on a utilisé le huitième bit, qui était
jusqu'alors inutilisé (enfin, pas vraiment : il était utilisé à des
fins de contrôle de l'intégrité des données, mais cela n'est plus très
utile car cette fonction est maintenant prise en charge par les
protocoles de communication), pour créer des "extensions" au code
ASCII. Ces extensions particulières sont des encodages, ou encore des jeux de caractères (charsets)
particuliers. En utilisant le huitième bit, on pouvait créer 128
caractères supplémentaires, ce qui était plus que suffisant pour y
placer pas mal de caractères accentués.

Ainsi, toute une flopée de jeux de caractères ont été créés, chacun
couvrant une plage de langues ou d'alphabets précis : ISO-8859-1 à
ISO-8859-15 notamment. Celui correspondant à notre alphabet occidental
est l'ISO-8859-1, mais il est de plus en plus remplacé par
l'ISO-8859-15 car ce dernier, plus récent, ajoute le support du signe
euro "¬".

Ces nombreux encodages ont rapidement créé des problèmes
d'incompatibilité. En effet, en l'absence d'informations, comment
savoir si le caractère portant la valeur 233 est un "é", comme en
ISO-8859-1, ou la lettre hébraïque "yod", comme en ISO-8859-8 (alphabet
hébreu) ?

Pour éviter ce genre de dilemme, chaque document transmis ou enregistré
porte en général à "proximité" (par exemple, dans un en-tête HTTP),
voire dans le document lui-même (comme en XML) un champ indiquant le
jeu de caractères dans lequel il a été encodé. Le cas échéant, le
logiciel de lecture se replie en général vers un encodage par défaut
(souvent, le plus répandu).

Mais que se passe-t-il si le logiciel se
trompe et choisit le mauvais encodage, parce que l'encodage par défaut
n'est pas le bon, ou parce que l'information d'encodage livrée avec le
document est erronée ?


Eh bien, vous vous en doutez, on a droit à quelques problèmes ! Le plus
souvent, le logiciel arrivera tout de même à afficher le document, mais
tous les caractères accentués seront tout simplement massacrés (les
caractères "normaux" sont épargnés car il s'agit de la base ASCII,
commune à tous les encodages).

Le plus souvent, on est confronté à deux cas : soit le document est lu
en ISO-8859-1 alors qu'il est encodé en UTF-8 (encodage que nous
verrons un peu plus loin), auquel cas vous verrez des caractères de ce
style à la place des accents : "Ã" (très joli, n'est-il pas ?
), soit le document est lu en UTF-8 alors qu'il est encodé en
ISO-8859-1 (plus rare, sauf en XML), auquel cas tous les accents seront
tout simplement remplacés par des "?".

D'où l'intérêt de faire attention à bien vérifier que l'encodage spécifié est bien celui avec lequel on encode le document !

D'accord pour les problèmes d'encodage, mais
il y en a un autre : comment faire pour écrire des glyphes latins,
hébreu, chinois et russes dans la même page ? Par exemple, pour un
cours d'histoire des langues ? Quel encodage ISO-8859-truc dois-je
utiliser ?


Aucun.
En fait, il n'est pas possible de stocker toutes ces possibilités dans
les 128 combinaisons possibles. On n'a donc pas le choix : il faut
agrandir l'espace, c'est-à-dire s'étendre sur plus d'un octet par
caractère.

Oui, mais si on double chaque caractère (par exemple), la taille du document va doubler ! Il n'y a pas une meilleure solution ?


Si. En fait, on va utiliser le fameux huitième bit comme "indicateur
d'encodage" : par exemple, on peut dire que s'il est à 0, il s'agit
d'un caractère ASCII, et s'il est à 1, on est en présence d'un glyphe
non standard et que ici, et ici uniquement,
on va le coder avec deux octets. Cela nous donne donc les 7 bits du
premier octet plus les 8 bits du second octet, soit 15 bits, soit
encore 32768 possibilités. D'un coup, on se sent plus à l'aise !

Ce type d'encodage existe : il s'agit du "célèbre" UTF-8.

Attends, je pige pas là : pourquoi tout le
monde ne se met pas à utiliser de l'UTF-8, puisqu'il est bien meilleur
que les encodages de la série ISO ?


Pour plusieurs raisons (pour info, le Site du Zéro travaille en UTF-.

• UTF-8 est un jeu de caractères récent par rapport aux autres. Il
  est longtemps resté méconnu et peu utilisé. Du coup, l'habitude
  d'utiliser ISO-8859-1 reste encore solidement répandue.
  
• UTF-8 n'est d'aucune utilité si vous êtes absolument certains que
  vous allez rester dans un alphabet bien précis (l'alphabet latin, par
  exemple). Auquel cas, il peut s'avérer plus judicieux d'utiliser un
  encodage de la série ISO car un caractère accentué y prend moins de
  place qu'en UTF-8.
  Attention : quand je dis "absolument certains", c'est vraiment certain
  de chez certain : par exemple, irez-vous jurer sur votre tête que vous
  n'insérerez jamais de caractère hébreu ou russe sur votre blog ? Sur un
  billet ayant pour sujet l'encodage des caractères par exemple, ou sur
  une langue précise ?
  
• Surtout, le principal obstacle à la généralisation d'UTF-8 est que,
  contrairement aux encodages classiques, il faut que les logiciels
  soient adaptés. Pourquoi ? Parce que dans un encodage classique, le
  nombre d'octets est le même que le nombre de caractères (vu qu'un octet
  égale un caractère). Avec UTF-8, cette égalité ne tient plus. Du coup,
  le comportement des programmes non conçus pour gérer l'UTF-8 peut se
  révéler étrange avec ces types de documents. Il faut également signaler
  que pour cette même raison, une chaîne en UTF-8 est plus longue à
  traiter qu'une chaîne en encodage classique.
  

Tout ça est bien joli, mais je ne sais même pas quel jeu de caractères j'utilise pour mon application/page web/documents !


Si vous ne savez pas quel encodage vous utilisez, il y a gros à parier qu'il s'agit de ISO-8859-1 (aussi appelé latin1).

LIRE LA SUITE...

Source:
http://www.siteduzero.com/tutoriel-3-36943-comprendre-les-jeux-de-caracteres-et-interclassements.html