Dynamic-Mess.com


"The world is a dynamic mess of jiggling things..."

Comprendre les jeux de caractères et l'interclassement (charset et collation)

Article posté le 19-01-2015 dans la catégorie SQL

Il est assez courant de voir sur les sites Internet et les forums de multiples et redondantes questions concernant les jeux de caractères, des problèmes d'accents, les caractères spéciaux, notamment pour les bases de données.
Sans compter les confusions entre jeux de caractères, encodage, interclassement...

Le but de cet article est de clarifier tout cela.
Nous verrons donc :

Noter que pour les exemples, nous utiliserons le SGBD MySQL.

1) Les jeux de caractères (charset)

Cette partie est importante, car les gens confondent les deux...

A- Les charsets, aux origines

Pour comprendre cette notion, il faut savoir que votre ordinateur ne connait pas les lettres, il ne connait que des nombres. Aux début de l'informatique, on a donc des CHARSET : créer un tableau de correspondance entre nombres et lettres.

Le premier est le célèbre ASCII. Chaque caractère a donc un code ASCII.  Le code ASCII est défini sur 7 bits ce qui lui permet de contenir 128 caractères. Le huitième bit étant utilisé pour d'autres considération, le code ASCII tenait donc sur 8 bits, un octets.


Seulement voilà, au début de l'informatique, où l'anglais était la seule langue utilisée, cela suffisait, mais avec sa démocratisation, 128 places n'étaient pas suffisantes pour contenir tous les caractères existants, comme ceux avec les accents par exemple. On a donc créé un nouveau CHARSET, utilisant un octet supplémentaire, permettant de doubler l'espace disponible (65536 possibilités) : ainsi est né l'UNICODE.

ASCII et UNICODE sont donc des charsets. Ils ont, vous l'avez compris : une fonctionnalité bien précise : faire une correspondance entre un caractère et sa valeur numérique via un tableau de correspondance.

B- Encodage

L'encodage se situe avant le charset. Sa fonction est de transformer des nombres en données binaires. C'est pour cela que vous avez des logiciels qui vous proposent d'enregistrer un fichier avec tel ou tel encodage. Pourquoi plusieurs encodages? Leurs capacités et leur gestion de la mémoire ne sont pas les mêmes.


Et c'est ainsi que l'on a créé tout une liste d'encodages : souvent, pour un alphabet précis. Par exemple, pour l'alphabet occidental, on utile le ISO-8859-1 voire le ISO-8859-15 qui rajoute le sigle Euros. Ainsi, c'est de là que vient la confusion, on parle de jeu de caractères unicodes.

Exemple sur la doc MySQL :

MySQL 5.0 has two Unicode character sets:
ucs2, the UCS-2 encoding of the Unicode character set using 16 bits per character
utf8, a UTF-8 encoding of the Unicode character set using one to three bytes per character
You can store text in about 650 languages using these character sets

Vous avez donc compris : on parle de "jeu de caractère Unicode avec l'encodage xxx" (UTF-8 par exemple). C'est pour cela que dans MySQL, c'est dans la colonne Charset, que vous choisirez votre encodage, ce qui porte à confusion.

Mais revenons à nos encodages.

Cela présente cependant un problème : si l'application qui ouvre le document ne connait pas l'encodage
utilisé, comment savoir à quoi correpond le code des caractères lus?

C'est pour cela que la plupart du temps, c'est le cas, les fichiers XML par exemple le spécifient en début de document, ou encore les pages Web dans l'entête HTTP, si le développeur y a pensé... En l'absence d'informations, il prendra l'encodage par défaut.

Ce qui implique que si le logiciel choisit le mauvais encodage (ou le développeur), certains caractères apparaitront
de manière plus ou moins étranges, c'est le moins que l'on puisse dire!

Afin de résoudre ce problème, et de donner plus de possibilités aux développeurs / rédacteurs qui voudraient faire appel à des
caractères contenu dans différents encodages, on en a créé un nouveau : UTF-8.
Ce petit nouveau utilise les 7 premiers bits - comme les précédents - pour représenter les caractères, en l'occurence ici ceux présents dans le code ASCII, mais utilise le huitième pour préciser s'il ne s'agit pas d'un caractère présent dans le code ASCII.
Dans ce cas, l'encodage passe de 7 bits utilisés, à 15, soit 32768 possibilités! Avec UTF-8, tout vos problèmes sont réglés (même si cela présente une place supplémentaire requise en termes de stockage).

Quelques informations sur l'UTF-8 :

2) L'interclassement (collation)

Un interclassement est un tableau qui liste la correspondance des caractères d'un jeu de caractère en particulier.
Un jeu peut avoir plusieurs interclassements, un par langue généralement. Le but est de permettre, par exemple, de classer par ordre alphabétique les caractères. Ainsi votre SGBD saura intepréter des requêtes de tri, mais également savoir si un caractère est équivalent à un autre, par exemple le 'a' et le 'à'.

3) Quelques astuces

A- Création et altération d'une table et de ses données

Vous pouvez spécifier un jeu de caractères et / ou un interclassement pour :

Lors de la création d'une table ou d'une colonne, les paramètres de la base sont pris par défaut si vous ne spécifiez rien.
Il est également possible de modifier ces paramètres après coup. Mais attention :

Un ALTER sur une colonne entraîne automatiquement la conversion des données déjà présentes dans cette colonne !
La commande suivante permet elle de convertir toutes les colonnes de votre table :

ALTER TABLE votretable CONVERT TO CHARACTER SET votre_jeu_de_caracteres COLLATE votre_interclassement

B- Type de données

4) Gérer la communication avec le SGBD

Enfin, sachez qu'il est possible de spécifier à MySQL les infos sur les données que l'on lui envoie et sur celles que l'on doit recevoir. Ainsi une application peut utiliser UTF-8 et le SGBD utiliser ISO-8858-1 sans problème de compréhension. Pour cela, on a 4 paramètres principaux à préciser à chaque connexion à MySQL.

Les deux principaux :

Mais aussi :

Voilà, vous savez l'essentiel! Vous pouvez compléter, en cas de soucis avec vos sites Web, avec cet article.


Tweet
comments powered by Disqus