3
Je dois écrire du code en utilisant le codage de caractères. Y a-t-il une bonne introduction au sujet pour me lancer?Où puis-je trouver une bonne introduction à l'encodage de caractères?
A
Répondre
5
Publié pour la première fois à What every developer should know about character encoding.
Si vous écrivez du code qui touche un fichier texte, vous en avez probablement besoin.
Lets commencer avec deux éléments clés
1.Unicode ne résout pas ce problème pour nous (encore).
2.Chaque fichier texte est codé. Il n'y a pas de fichier non codé ou d'encodage "général". Et ajoute un codacil à cela - la plupart des Américains peuvent s'en sortir sans avoir à en tenir compte - la plupart du temps. Parce que les caractères pour les premiers 127 octets dans la grande majorité des schémas de codage correspondent au même ensemble de caractères (plus précisément appelés glyphes). Et parce que nous n'utilisons que A-Z sans autres caractères, accents, etc. - nous sommes prêts à partir. Mais la seconde vous utilisez ces mêmes hypothèses dans un fichier HTML ou XML qui a des caractères en dehors de la première 127 - alors le problème commence.
L'industrie informatique a commencé avec l'espace disque et la mémoire à un niveau élevé. Quiconque a suggéré d'utiliser 2 octets pour chaque personnage au lieu d'un aurait été raillé. En fait, nous avons de la chance que l'octet fonctionne mieux en 8 bits ou que nous ayons moins de 256 bits pour chaque caractère. Il y avait bien sûr de nombreux jeux de caractères (ou pages de codes) développés très tôt. Mais nous nous sommes retrouvés avec la plupart des gens utilisant un ensemble standard de pages de code où les 127 premiers octets étaient identiques sur tous et les seconds étaient uniques à chaque ensemble. Et puis pour l'Asie, parce que 256 caractères n'étaient pas suffisants, certains de la gamme 128 - 255 avaient ce qu'on appelait DBCS (jeux de caractères à double octet). . Pour chaque valeur d'un premier octet (dans ces plages supérieures), le deuxième octet identifie l'un des 256 caractères. Cela a donné un total de 128 * 256 caractères supplémentaires. C'était un hack, mais cela permettait de minimiser l'utilisation de la mémoire. Le chinois, le japonais et le coréen ont chacun leur propre page de codes DBCS.
Et pendant un certain temps cela a bien fonctionné. Les systèmes d'exploitation, les applications, etc. étaient principalement configurés pour utiliser une page de code spécifiée. Mais ensuite Internet est arrivé. Un site Web en Amérique utilisant un fichier XML en provenance de Grèce pour afficher des données à un utilisateur naviguant en Russie, où chacun entre des données basées sur son pays - qui a brisé le paradigme.
Avance rapide jusqu'à aujourd'hui. Les deux formats de fichiers où l'on peut expliquer le mieux, et où tout le monde trébuche, est le HTML et le XML. Chaque fichier HTML et XML peut éventuellement avoir l'encodage de caractères défini dans ses métadonnées d'en-tête. Si ce n'est pas le cas, la plupart des programmes supposent que c'est UTF-8, mais ce n'est pas une norme et elle n'est pas universellement suivie. Si le codage n'est pas spécifié et que le programme lisant le fichier est erroné, le fichier sera mal lu. Point 1 - Ne jamais traiter en spécifiant l'encodage comme facultatif lors de l'écriture d'un fichier. Toujours l'écrire dans le fichier. Toujours. Même si vous êtes prêt à jurer que le fichier ne comportera jamais de caractères de 1 à 127.
Maintenant, regardons UTF-8 parce que le standard et la façon dont ça fonctionne, ça fait beaucoup de monde d'ennuis. UTF-8 était populaire pour deux raisons. Tout d'abord, il correspondait aux pages de code standard pour les 127 premiers caractères et donc la plupart des HTML et XML existants le correspondaient. Deuxièmement, il a été conçu pour utiliser le moins d'octets possible, ce qui a beaucoup compté lors de sa conception et de nombreuses personnes utilisaient encore des modems d'accès commuté.
UTF-8 emprunté aux conceptions DBCS des pages de code asiatiques. Les 128 premiers octets sont tous des représentations de caractères à un octet. Ensuite, pour l'ensemble suivant le plus commun, il utilise un bloc dans les 128 octets deuxième pour être une séquence de double octet nous donnant plus de caractères. Mais attendez, il y a plus. Pour les moins communs, il y a un premier octet qui conduit à des sersies de second octets. Ceux-ci conduisent chacun à un troisième octet et ces trois octets définissent le caractère. Cela va jusqu'à des séquences de 6 octets. En utilisant le MBCS (jeu de caractères multi-octets), vous pouvez écrire l'équivalent de chaque caractère Unicode. Et en supposant que ce que vous écrivez n'est pas une liste de caractères chinois rarement utilisés, faites-le en moins d'octets.
Mais voici ce que tout le monde trébuche - ils ont un fichier HTML ou XML, ça marche bien, et ils l'ouvrent dans un éditeur de texte. Ils ajoutent ensuite un caractère qui, dans leur éditeur de texte, en utilisant la page de codes pour leur région, insère un caractère comme ß et enregistre le fichier. Bien sûr, il doit être correct - leur éditeur de texte le montre correctement. Mais donnez-le à n'importe quel programme qui lit selon l'encodage et qui est maintenant le premier caractère d'une séquence de 2 octets. Vous obtenez un caractère différent ou si le deuxième octet n'est pas une valeur légale pour ce premier octet - une erreur. Point 2 - Toujours créer HTML et XML dans un programme qui l'écrit correctement en utilisant le codage. Si vous devez créer avec un éditeur de texte, affichez le fichier final dans un navigateur.
Maintenant, qu'en est-il lorsque le code que vous écrivez va lire ou écrire un fichier? Nous ne parlons pas de fichiers binaires/de données dans lesquels vous écrivez dans votre propre format, mais de fichiers qui sont considérés comme des fichiers texte. Java, .NET, etc ont tous des encodeurs de caractères. Le but de ces encodeurs est de traduire entre une séquence d'octets (le fichier) et les caractères qu'ils représentent. Prenons ce qui est en fait un exemple très difficile - votre code source, que ce soit C#, Java, etc. Il s'agit toujours en gros de "vieux fichiers texte" sans indicateurs de codage. Alors, comment les programmes les gèrent-ils? Beaucoup supposent qu'ils utilisent la page de codes locale. Beaucoup d'autres supposent que tous les caractères seront dans la gamme 0 - 127 et s'étrangleront sur n'importe quoi d'autre.
Voici un point clé sur ces fichiers texte - chaque programme utilise toujours un encodage. Ce n'est peut-être pas le code, mais par définition, un encodage est utilisé. Point 3 - Toujours définir le codage lorsque vous lisez et écrivez des fichiers texte. Pas seulement pour HTML & XML, mais même pour des fichiers comme le code source. C'est bien si vous le définissez pour utiliser la page de codes par défaut, mais définissez l'encodage. Point 4 - Utiliser le codeur le plus complet possible. Vous pouvez écrire votre propre fichier XML en tant que fichier texte codé pour UTF-8. Mais si vous l'écrivez en utilisant un encodeur XML, alors il inclura l'encodage dans les méta-données et vous ne pouvez pas vous tromper. (il ajoute également le préambule endian au fichier.)
Ok, vous lisez & en écrivant correctement les fichiers mais qu'en est-il de votre code? Ce qu'il? C'est là que c'est facile - Unicode. C'est ce que les encodeurs créés dans Java & .NET runtime sont conçus pour faire. Vous lisez et obtenez unicode. Vous écrivez unicode et obtenez un fichier encodé. C'est pourquoi le type char est 16 bits et est un type de noyau unique pour les caractères. C'est probablement ce que vous avez raison parce que les langues d'aujourd'hui ne vous donnent pas beaucoup de choix en la matière. Point 5 - (Pour les développeurs sur des langages qui existent depuis longtemps) - Toujours utiliser unicode en interne. En C++, cela s'appelle des caractères larges (ou quelque chose de similaire). Ne soyez pas malin pour sauver quelques octets, la mémoire est bon marché et vous avez des choses plus importantes à faire.
il emballage jusqu'à
Je pense qu'il ya deux éléments clés à garder à l'esprit ici. Tout d'abord, assurez-vous de prendre l'encodage en compte sur les fichiers texte. Deuxièmement, tout cela est vraiment très simple et direct. Les gens bousillent rarement comment utiliser un encodage, c'est quand ils ignorent le problème qu'ils rencontrent.
4
De Joel Spolsky
Le logiciel Chaque Absolute minimum Developer Absolument, Positively doit savoir sur Unicode et les jeux de caractères (No Excuses!)
0
Comme d'habitude, Wikipedia est un bon point de départ : http://en.wikipedia.org/wiki/Character_encoding
0
J'ai une introduction de base sur mon blog, qui comprend également des liens vers des ressources en profondeur si vous voulez vraiment creuser dans le sujet.
http://www.dotnetnoob.com/2011/12/introduction-to-character-encoding.html
Le point 5 dépend de votre plate-forme. 'wchar_t' et UTF-16 est la façon dont Windows fait Unicode, mais les systèmes de type Unix ont tendance à préférer UTF-8. – dan04