Quelque soit le langage de programmation choisi pour réaliser un site web, vous pourrez être confronté à des problèmatiques communes. Et même si la mise en oeuvre de la solution pourra différer d'un langage à l'autre le principe reste le même.

Si vous souhaitez développer un site web destiné à être diffusé à travers la planète et surtout utilisé par des personnes parlant des langues différentes vous devrez trouver une solution aux problèmes connus sous les termes anglophones que sont "internationalisation" et "localisation" respectivement raccourcis sous les désignations i18n et l10n (où le nombre représente le nombre de lettre dans le mot et les lettres étant la première et dernière lettre du mot).

La localisation c'est tout simplement la possibilité qu'offre l'application d'être affichée dans la langue de l'utilisateur. L'application doit alors disposer des traductions des différents termes et phrases employées, elle doit être capable d'afficher les dates et autre informations dans le format habituel associé à la langue. Et donc, l'application doit être conçue pour faire appel à un dictionnaire (les traductions) chaque fois qu'elle doit afficher une phrase (plutôt que de "coder en dur" ces phrases).

L'internationalisation est un concept, moins évident à appréhender de prime abord mais qui est tout aussi important que la traduction. L'internationalisation c'est la capacité qu'a l'application d'afficher les jeux de caractères des différentes langues utilisées, ou encore d'afficher du texte de droite à gauche (plutôt que de gauche à droite).

Le problème de l'internationalisation est directement lié à celui de l'encodage des fichiers.

Un fichier est constitué de caractères stockés sous forme d'octets (1 octet = 8 bits). Jusque là, rien de nouveau. Mais le nombre d'octets nécessaire pour représenter un caractère dépend du nombre de caractères disponibles dans l'alphabet utilisé.

Si l'on ne considère que les caractères (non accentués) de a à z, de A à Z, de 0 à 9 quelques signes courants comme _,.,<;>, etc. Nous arrivons péniblement à 128 caractères (ceux de la table ASCII ^{[c'est quoi?]} ). Autrement dit il ne suffit que d'un octet (à peine. En fait 7 bits) pour représenter un caractère. Il est également possible de choisir d'utiliser l'ensemble des 8 bits d'un octet et en profiter pour ajouter quelques caractères "oubliés" comme certains caractères accentués. Nous avons alors la table ASCII étendue. Dans ces 2 cas, la gestion d'un fichier en lecture et en écriture est simple: à 1 octet correspond 1 caractère (et vice-versa). Il s'agit là d'un type possible d'encodage.

Seulement voilà, utiliser le bit de libre, pour ajouter 128 caractères en choisissant ces caractères parmi l'alphabet d'europe occidental ne répond pas à tous les besoins. Les grecs, par exemple, préfèrent utiliser cette possibilité d'étendre la table ASCII pour disposer d'avantage de caractères grecs. Ils utilisent alors de préférence, une autre variante de la table ASCII étendue. Dans ce cas, à 1 octet correspond toujours 1 caractère (et vice-versa) mais ce caractère diffère de celui de la table d'europe occidentale. Ces différentes règles de codage (ou encodage) sont baptisées ISO-8859-X (ou X varie selon l'alphabet retenu).

C'est ce type d'encodage qui est généralement utilisé par défaut par vos éditeurs de texte. Et notamment sous Windows ISO-8859-15 ou Cp1512 et sous Linux ISO-8859-1.

Nous venons, déjà de mettre le doigt sur un des problèmes posés par le choix de l'encodage. Seulement ce n'est pas tout, la table ASCII même étendue ne contient pas forcément tous les caractères nécessaires à une langue donnée. Il n'y a même pas besoin d'aller chercher une langue exotique pour trouver un exemple. En effet, la table ASCII étendue (ou toute autre version d'ISO-8859) ne permet pas d'afficher le caractère ? (oe collés). Et imaginez un peu le problème, si vous souhaitez avoir un fichier contenant à la fois des caractères occidentaux, des caractères arabes, cyrilliques et chinois....

Bref, il a fallu inventer une autre façon d'encoder les fichiers. En ayant cette fois pour objectif d'avoir un code unique pour chacun des caractères existants dans les différentes écritures. On parle alors d'encodage Unicode. Il y a deux principaux encodages unicode l'UTF-8 et l'UTF-16. Cette fois, à 1 caractère ne correspond pas nécessairement 1 seul octet. On pourrait même penser que chaque caractère est codé sur 3 ou 4 octets (selon le nombre de caractères que l'on a pu recenser sur l'ensemble des alphabets). Mais si tel était le cas, nos fichiers contenant des caractères occidentaux (dont la majeur partie des caractères font partie de la table ASCII) serait 3 ou 4 fois plus volumineux en encodage Unicode comparé à un encodage ISO-8859. Pour éviter ce type d'inconvénient, le nombre d'octets représentant un caractère dépend directement du caractère en question.

En UTF-8, un caractère appartenant à la table ASCII (non étendue) sera représenté par un unique octet, s'il n'y appartient pas alors il sera représenté par un premier octet d'échappement (octet ayant une signification particulière et d'une valeur > 127) suivi d'un second octet représentant son code dans une table étendue. Et si besoin, le code dans la table étendu sera sur 2 ou 3 octets (le nombre d'octets est déterminé par le caractère d'échappement).