Bannière du site

Guide utilisateur jAlbum

fleche_haut

jAlbum / Résolution des problèmes d'encodage de caractères

Contenus

Contexte

Obtenir des ordinateurs de présenter correctement le texte a été un défi depuis les débuts de l'informatique. Si vous êtes anglais, vous n'avez probablement pas réfléchi à ce sujet, mais le reste d'entre nous qui ont soi-disant des "caractères étrangers" comme å ä ö dans notre langue ont vu une ligne sans fin d'erreurs d'interprétation comme {, ?, Σ et dernièrement Ã¥.

Dans ce tutoriel, nous allons vous expliquer pourquoi cela se produit et comment vous pouvez ajuster jAlbum pour obtenir votre texte présenté juste.

Le problème de base est que les ordinateurs effectivement ne traitent pas nativement du texte. Les ordinateurs traitent avec les chiffres, les chiffres 0 et 1 pour être précis. Ces chiffres, appelés "bits", sont traités dans des groupes de 8 appelés "octet". Chaque octet peut représenter un nombre dans la gamme 0-255 où 0 est codé comme 00000000 (8 zéros) et 255 codées 11111111 (8 uns). Pour représenter un plus grand nombre, les octets sont combinés. En combinant deux octets (16 bits), on peut représenter des nombres dans la gamme 0-65535 et en combinant 4 octets (32 bits) donne une gamme de 0 à 4294967295 numéro. Jusqu'ici, tout va bien.


Problème

Les ordinateurs stockent le texte comme une séquence de nombres où chaque caractère possède un numéro unique conformément à un accord sur le "codage standard de caractères". Le problème est qu'il ya beaucoup de normes et chaque norme attribue des numéros différents pour le même caractère. "ä" est par exemple stockée sous forme de 228 dans la norme standard ISO-8859-1, mais stockée comme le nombre de deux octets 50084 dans la norme standard UTF-8 (écrit sous la forme c3a4 avec la notation hexadécimale). Si un codage UTF-8 "ä" est interprété conformément à la norme standard IS0-8859-1, il apparaît comme la paire de caractères "ä".


Solutions

Ce problème peut être traité de deux façons :

  • Le monde est d'accord à une seule norme
  • Avant d'envoyer le texte à un autre ordinateur (en fait des chiffres, vous vous souvenez ?), l'ordinateur émetteur dit d'abord quel est le standard utilisé

La première approche a historiquement été impossible de poursuivre car chaque norme a favorisé une région du monde sur une autre (Soutenir le suédois, mais pas le russe et vice-versa, par exemple). Aujourd'hui, il est une norme mondiale appelée "Unicode/UTF-8" qui gère tout caractère possible (et symbole) toutes les langues. Honnêtement, je dirais que le seul problème avec Unicode/UTF-8 est qu'il n'est pas utilisé partout.

Sur Internet, le Web et le courrier électronique utilisent la seconde approche: Avant qu'un document texte soit envoyé, l'ordinateur expéditeur passe le standard utilisé de codage de caractères (en utilisant la norme ASCII à propos). Les serveurs Web utilisent les dits "headers HTTP" pour cela. C'est généralement un paramètre de serveur Web. Les problèmes surviennent si le texte du document est écrit en utilisant un standard, mais les headers HTTP indique un autre standard. Pour démystifier les headers HTTP, voici un exemple d'une réponse d'un serveur web, où la norme est d'utiliser ISO-8859-1 :

HTTP/1.1 200 OK
Date: Mon, 19 Jan 2015 11:00:55 GMT
Server: Apache
Last-Modified: Sun, 18 Jan 2015 18:26:22 GMT
Content-Length: 4259
Content-Type: text/html; charset=ISO-8859-1


Remarque : Utilisez votre navigateur pour déterminer le type de contenu : pointer le navigateur vers une page HTML sur votre serveur, ouvrir les outils de développement (F12) et rechercher header HTTP pour charset.

jalbum42.jpg

Remarque : Si vous examinez le code source d'un document html, vous pouvez également voir que le jeu de caractères utilisé est indiqué dans une soi-disant "balise meta". Il semble toutefois que les ordinateurs préfèrent regarder l'en-tête HTTP, donc ne pas être confondus par cela. Vérifiez que le standard du serveur Web de codage correspond à l'encodage utilisé dans vos documents et vous serez parfait.


Configuration jAlbum

Par défaut jAlbum utilise la norme Unicode/UTF-8, mais si votre serveur Web est configuré pour utiliser une autre norme, soit changer votre serveur Web pour Unicode/UTF-8 et mettre à jour les documents existants ou modifier jAlbum pour correspondre à la norme utilisée par votre serveur Web. Nous vous recommandons de passer à Unicode/UTF-8 comme cela on ne discrimine aucune langue. C'est également une norme qui est utilisée de plus en plus massivement chaque année. Si vous décidez de changer l'encodage de jAlbum à la place de celle-ci, juste aller dans Paramètres->Avancées->Général et décochez "Encoder en UTF-8" ajuster le réglage de "Encodage" pour correspondre à celui de votre serveur. Une fois terminé, faire et téléverser de nouveau les pages.

FTP et les liens rompus

Jusqu'à présent, nous avons parlé de l'obtention de texte s'affichant correctement dans les pages Web, mais ces problèmes d'encodage peuvent également causer des problèmes lorsque vous cliquez sur les liens pour aller d'une page web à l'autre si le lien de la page Web ou la cible contient des caractères étrangers dans son nom de fichier. La meilleure solution consiste à rester à l'écart de l'utilisation des caractères étrangers dans les noms de fichiers et de dossiers, mais si vous voulez les utiliser, assurez-vous que le serveur où vous téléchargez interpréte correctement les noms de fichiers lorsque vous transférez les fichiers sur le serveur. La plupart des serveurs ftp diront correctement aux clients ftp si ils attendent des noms de fichiers d'être encodés ou non en Unicode/UTF-8, mais certains serveurs FTP disent qu'ils ne prennent pas en charge Unicode/UTF-8, même si ils attendent des noms de fichiers encodés comme ça. Pour résoudre ce problème, jAlbum bénéficie d'un paramètre "Forcer UTF-8" qui peut être coché dans Téléversement->Envoyer/Gérer->Avancées.

Caractères spéciaux

Lorsque vous nommez des fichiers pour une utilisation sur le web, aussi faire attention à ne jamais utiliser de caractères qui sont réservés à des usages particuliers. Il s'agit de #$%&*"\/:;?=|. Si par exemple vous utilisez un slash "/" ou un hash "#" dans un nom de fichier, vous briserez les liens vers ces fichiers car le slash est utilisé pour séparer des fichiers et dossiers et le hash est utilisé pour signaler des sections d'un fichier. Par défaut, jAlbum vous empêche d'utiliser des caractères spéciaux dans les noms de fichiers.

Unicode et UTF-8

Unicode est un standard de l'industrie informatique pour la cohérence de l'encodage, la représentation et la manipulation de texte exprimé dans la plupart des systèmes d'écriture du monde. UTF-8 est une soi-disant "implémentation d'Unicode" et le meilleur à utiliser je dirais. Il y a également d'autres implémentations Unicode comme UTF-16 et UTF-32. Ces implémentations sont juste des façons différentes pour, au niveau binaire, enregistrer le numéro unique qui a été attribué à chaque caractère en fonction de la norme Unicode. UTF-16 utilise toujours 16 bits pour exprimer chaque caractère. Cela signifie que UTF-16 est limitée à la manipulation d'un maximum de 65536 caractères différents. Pour surmonter cette limitation UTF-32 a été développé qui utilise toujours 32 bits. Il est donc capable de gérer 4294967295 caractères différents.

Peut-être que cela sonne bien, mais il y a quatre inconvénients à l'utilisation d'UTF-16 et UTF-32 :

  • Comme chaque caractère consomme 2 ou 4 octets, le texte anglais ordinaire consomme 2-4 fois plus d'espace par rapport aux anciennes normes
  • Il n'est pas rétrocompatible avec l'ancienne et répandue norme ASCII
  • UTF-16 est disponible en deux variantes en fonction de l'ordre des octets dans chaque paire, ce qui provoque une mauvaise interprétation
  • Le texte en UTF-16 et UTF-32 peut être mal interprété si l'ordinateur interprète est désynchronisé, lors de la lecture, en même temps, des groupes de 2 ou 4 octets (lire les paires d'octet AABBCC comme AB BC etc. au lieu de AA BB CC)

UTF-8 résout tous ces problèmes ! C'est un système de longueur variable qui est compatible avec l'ASCII. Cela signifie que le texte anglais ordinaire est stocké comme la norme ASCII. Cela rend également UTF-8 compact pour la plupart des textes. Les caractères étrangers consomment 2-6 octets en fonction du caractère à coder. UTF-8 utilise un schéma binaire intelligent pour veiller à ce que l'ordinateur récepteur ne lise jamais désynchronisé un flux d'octets. Enfin, ce schéma permet également aux ordinateurs d'identifier automatiquement le texte codé en UTF-8.