encodage fichierWorkbench® Visual Integrator ™ (VI) prend en charge divers types d'encodage de fichiers. Lorsque vous avez des entrées provenant de plusieurs sources, assurez-vous que l'encodage correspond bien à chacun de vos fichiers d'entrée. Il suffit de regarder une entrée Filein et vous pourrez constater qu'il prend en charge les codages suivants: auto, ascii, GB 18030, latin1, utf-8, unicode, unicode-be et unicode-le. De même, Builder ™ et Spectre ™ prennent également en charge ces codages.

Certes, ce sujet est assez geek, mais cela pique-t-il votre curiosité de plonger dans l'histoire ésotérique du codage de fichier numérique? Quelles sont les options? Pour répondre à ces questions, pour comprendre pourquoi différents types d’encodage sont utilisés et pour faire les bons choix en toute confiance pour vos données, commençons par le début.

Au début…

Tout texte sous forme numérique comporte une forme de codage, une traduction des bits et des octets du fichier en caractères et chiffres réels. Dans des circonstances normales, tout bloc d'octets n'a de sens que si le code est apparent ou donné.

Au début du numérique, la gamme de caractères nécessitant un codage était petite, seules les lettres de l'alphabet latin ou même les majuscules. Ils sont tous rentrés dans un octet de 8 bits. Un des premiers encodages, conçu par IBM, était EBCDIC du début des années soixante du siècle précédent. Très étrange si vous êtes habitué à ASCII, mais EBCDIC est toujours présent dans les Mainframes et les AS / 400. Le code coupe l'octet en deux, en utilisant une moitié pour désigner la variante et l'autre pour coder les caractères.

Plus tard, il y a eu ASCII (ANSI dans la terminologie Microsoft). ASCII utilise 7 bits dans un octet. Le premier bit est mis à 0. Par conséquent, les codes 0-127 sont utilisés de manière décimale. Si le premier bit est à un (128-255), il est appelé ASCII étendu. Au début, ces caractères ASCII «élevés» étaient le foyer de caractères spéciaux comme Ç et de symboles tels que:

encodage fichier 2

Cela a permis à un programmeur de dessiner des écrans d’utilisateurs complexes, avant l’avènement des interfaces graphiques, qui ne sont pas tout à fait morts de nos jours.

Cependant, la porte étant ouverte, certains ont utilisé la partie étendue pour stocker d'autres caractères comme l'alphabet grec ou le russe. "Stocker des caractères grecs" n’est pas tout à fait correct. Ce qui était stocké était toujours le numéro 128, mais maintenant sa signification a changé : il veut dire "alpha" et non plus Ç.

Pages de code

Au fil du temps, beaucoup de ces ensembles de la partie étendue ont été créés et appelées "page de code". Cela n'a pas modifié la valeur réelle des octets des fichiers informatiques, mais simplement la manière dont ils sont restitués par les systèmes d'interface.

Les pages de code ont été normalisées, numérotées et nommées. Plusieurs fois. Il existe des numéros de CP pour "code pages", des numéros ISO et des noms comme latin 1, AKA ISO-8895-1, AKA CP1252. Cette page de code latin1 utilise uniquement un certain nombre de bits possibles. Les combinaisons de caractères diacritiques couramment utilisées dans les systèmes d'écriture européens (pas les langues!), comme ß, y figurent.

Aussi pratique que soit le système de pages de code, il posait plusieurs problèmes. Premièrement, il était très difficile d’avoir à la fois le grec et, par exemple, l’hébreu dans un texte (ce qui est problématique si vous êtes un érudit biblique) ou le russe et le grec. Mais, plus problématique encore, aucun système d'écriture non alphabétique du monde ne pouvait être adapté. Les systèmes syllabiques ont beaucoup trop de signes pour exprimer leur variété en 8 bits. Ainsi, une nouvelle approche (et encore plus de numéros ISO) était nécessaire : Unicode.

Unicode

Contrairement à son nom, Unicode n'est pas un code, pas un système de codage mais une liste. Une très longue liste de caractères, commençant à 0 et se déroulant jusqu'à l'infini ou presque. Vous trouverez une liste absolument géniale sur le site Web de https://unicode-table.com/en/, qui attribue également des groupes de caractères à un système d'écriture, aux langues et à leur utilisation géographique. Parmi mes préférés figurent les hiéroglyphes égyptiens cunéiformes et le script vieux de 4000 ans de la Crète, toujours pas déchiffré. Cette liste n'est pas figée et nous en sommes actuellement à la version 11.0.

Encodage

Maintenant, prenez le glyphe (qui signifie «appeler» semble-t-il). Il s'agit du numéro x1301E ou du nombre décimal 77854 dans la liste Unicode. Comment pouvons-nous «stocker» ce numéro dans un fichier? Evidemment, cela ne rentrera pas dans un octet. Mais comment allons-nous adapter les bits dans: 0001-00110000-00011110. Nous ne pouvons pas prendre trois octets pour cela, car comment saurions-nous que le premier octet fait partie de quelque chose de plus grand? Avec l'encodage Unicode.

Il fallait trouver un moyen de coder ces grands nombres en octets (plus d'un évidemment) sans avoir à coder la lettre A sous la forme 00.00.00.40, autrement dit, utiliser quatre octets (voire plus lorsque la liste Unicode est encore plus étendue) pour chaque caractère. Ce serait plutôt inefficace.

UTF-8

Une invention intelligente était le codage UTF-8. Il utilise essentiellement un octet si le nombre tient dans 7 bits et 8 bits supplémentaires pour chaque étape supérieure. D'où son nom UTF- 8. Devinez combien sont utilisés en UTF-16? La raison pour laquelle seulement 7 bits sont utilisés est que nous avons besoin d'un bit pour signaler qu'il y a plus à venir pour ce nombre ou ce caractère. UTF-8 était très intelligent, car les numéros Unicode pour AZ et les autres textes ASCII non étendus coïncident entièrement avec les codes ASCII. Même le premier bit zéro est le même. Ainsi, un texte ASCII non étendu peut être pris pour être encodé gratuitement en UTF-8. Selon la rumeur, concevoir UTF-8 était le seul moyen d'intéresser les Américains à l'Unicode, car il est évident que la langue anglaise (et même américaine) peut très bien se passer des valeurs au-delà de az et AZ. Il est également important de réaliser que l'UTF-16 ne s'étend pas uniquement en 16 bits, il commence également en 16 bits. Ainsi, la majorité des textes numériques du monde, qui tiennent en 8, prennent le double de place! 

UCS-2

Pendant ce temps, Microsoft avait ses propres idées. Il a codé l'UCS (Universal Coded Character Set), identique (à présent) à la liste Unicode, en codage UCS-2 . Cela ressemble beaucoup à UTF-16, notamment parce qu'il utilise deux octets pour commencer. C’est ce que MSSQL utilise, par exemple, et la raison pour laquelle il est deux fois plus grand que toute autre base de données utilisant UTF-8. Dans un effort extrême pour créer une confusion maximale avec le moins de mots (ou d’octets de code), ce codage UCS-2 est parfois appelé… « Unicode». Pourquoi faire simple… Ne pensez pas que le vieux Bill a le monopole des décisions remarquables: Big Blue (IBM) a un numéro de page de code pour… le codage UTF-8 (1208). Et Diver® utilise les deux!

Collation

Une autre méthode utilisée avec les jeux de caractères et les codages est la collation ou collationnement. Ceci est principalement utilisé dans les systèmes qui ont besoin de faire quelque chose avec des textes, comme du tri. Les bases de données l'utilisent. Le célèbre mysql, d'origine suédoise dans son passé Open Source, utilisait un classement par défaut de latin1_swedish_ci. Cela signifie que, par exemple, lors du classement du texte, les ensembles d'octets seront interprétés comme des caractères latin1 ascii, insensibles à la casse (AaBb) et comportant des règles pour les caractères suédois spéciaux. Je suppose que Å vient après A...). Je vous laisse deviner le nombre de bases de données mysql qui ont conservé ce défaut...

Encodage dans Integrator

Diver ou, dans ce cas, Integrator, prend en charge divers encodages. En fait, la liste est plutôt remarquable. Ce sont: auto, ascii, gb 18030, latin1, utf-8, unicode, unicode-be, unicode-le.

Endianisme

Pour commencer avec les deux derniers, unicode-be et unicode-le, nous devons apporter des précision : les fichiers informatiques peuvent avoir une BoM, Byte Order Mark. Une BoM est un nombre d'octets au début d'un fichier avec une signification spéciale. En général, les nombres multi-octets peuvent avoir différents ordres dans lesquels les octets sont stockés. Le nombre décimal 259 est stocké dans deux octets, x01 et x03. Le premier octet est 256 en 'valeur' ​​et le deuxième 3. Ainsi, le premier octet est la valeur la plus significative, la plus élevée. Pour des raisons étonnantes, certains processeurs stockent ces octets dans des ordres différents, avec l'octet le plus significatif en premier (MSB) ou l'octet le moins significatif en premier (LSB). Donc, 259 peut être numériquement x0103 ou x0301. Internet utilise MSB, tout comme les processeurs mainframe Motorola, Sparc et IBM. Apple et Intel utilisent LSB. MSB est également appelé Big Endian (comme suit: le Big End vient en premier) et LSB est Little Endian.

Ainsi, nous avons déjà vu que Unicode dans ce contexte signifie en réalité UCS-2. Nous savons maintenant ce que représentent les noms spécifiques Unicode-be (big endian) et Unicode-le (little endian). Si jamais le paramètre de codage Unicode dans Integrator perturbe un fichier texte, mais que vous savez qu'il se trouve dans UCS-2, essayez l'un des Big ou Little Endians…

Nous connaissons latin1, ascii. GB18030 est l'ensemble des codes officiels chinois pour les caractères chinois simplifiés et traditionnels... Il nous manque "auto".

Dériver l'encodage

"auto" définit l'encodage "en fonction de la signature du fichier et de l'état Unicode des autres objets de la même tâche". C’est une caractéristique très utile et souvent suffisante. Mais allons un peu plus loin et voyons ce que l'on peut apprendre du fichier lui-même en l'examinant. Nous devons revenir à la BoM une fois de plus. Ces marques d'octets n'indiquent pas simplement au processeur destinataire quel est l'ordre des octets, mais également que la pièce est codée en Unicode et quel codage. Donc, l’ouverture avec les octets FF FE est UTF-16 Little Endian, et l’inverse entre FE FF et Big Endian.
Il y a une spécificité pour UTF-8 : comme il s’agit d’un système de codage à un octet, une BoM n’est pas nécessaire, mais il existe tout de même une marque pour UTF-8 (EF BB BF). Son utilisation n'est pas prescrite et beaucoup de UTF-8 ne sont pas marqués ainsi. Maintenant, il existe de nombreuses combinaisons de bits non valides. Le test heuristique d’un fichier peut donc déterminer qu’il est probablement NON codé en UTF-8, du moins non valide UTF-8, de sorte qu’il s’agit probablement d’un code ASCII.

Deviner la page de code

Comment deviner une page de code? Si un caractère (128) dans un texte sur un seul octet est précédé des caractères "gar" et suivi de "on", il y a de bonnes chances que le "garçon" en français soit visé, et le 128 n'est pas un alpha grec, ni autre chose. Mais, pour prédire en toute sécurité les codages sur un octet, vous aurez besoin soit d'une vaste connaissance des langages du monde, soit d'une chance démesurée!

Donc, comme pour interpréter correctement les données elles-mêmes, rien ne remplace «Know Thy Data» et dans ce cas, Thy Encodage. Parfois, vous aurez besoin de savoir quel encodage est utilisé à la source, d'où proviennent les données.

Recommandations

Enfin, voici quelques recommandations avec Integrator:

  • En règle générale, ne perdez pas d'informations. Si une source est en Unicode, comme c'est le cas régulièrement, conservez-la ainsi.
  • Les encodages de fichiers doivent-ils être convertis? Il est important de noter que les conversions n'augmentent généralement que leur complexité et pas la sécurité. Il est tout à fait déconseillé d’essayer de convertir une source codée en UTF-8 en un seul octet ASCII. Cela pourrait fonctionner très bien de convertir en latin1... jusqu'à ce qu'une nouvelle personne entre dans la base de données avec un nom comportant des caractères non-pris en charge par latin1. Ne pensez pas "nous ne ferons pas de chinois avant longtemps" - cela pourrait être beaucoup plus proche que vous ne le pensez.
  • Integrator utilise UTF-8 en interne. Il est recommandé de sauvegarder également les fichiers intermédiaires au format UTF-8. Toutefois, si vous n'utilisez pas une version de Diveline compatible avec Unicode (et d'autres produits DI), il y aura une conversion silencieuse vers le format ascii sur 1 octet dans le modèle ou la base de données cBase. Si votre source n’est pas UTF-8 ou latin1, ceci est potentiellement dangereux. (Votre alpha grec se transformera en Ç sans aucun indice sur ce qu'il était auparavant.)
  • Regardez ce qui se passe dans votre objet Integrator Filein. Il n'y a qu'un seul réglage pour l'encodage. Donc, divisez vos fichiers-Ins si vous avez des fichiers avec des encodages différents. Soyez aussi explicite que possible et évitez de vous fier à «auto».

Et quelques notes de côté:

  • Il est possible que Integrator ne puisse pas encore prendre en charge les textes encodés. Puisque latin1 est la seule page de code mentionnée, ce n’est pas si difficile à imaginer. Ce n'est pas un problème si tout le système est dans le même encodage. Par exemple, un client DI utilise CP1255 (Hébreu). En un sens, Diver n'a pas besoin de le savoir. Qu'une valeur de dimension soit ùìåí ou שלומ (shalom), Diver s'en fiche. Dans des circonstances normales, Diver demandera aux paramètres régionaux du système comment restituer les lettres. Mais même dans ce cas, il est logique de convertir en Unicode et d’être prêt pour l’avenir à se mélanger à d’autres scripts et à créer des exportations conformes aux normes modernes.
  • Si un fichier est livré dans une ascii à un octet autre que latin1, la conversion ne peut pas être effectuée par Integrator. La conversion peut être effectuée à l'aide d'un outil externe tel que iconv, facilement logé dans une extension Production®, en le convertissant au format UTF-8 avant traitement. 
  • Il existe une différence entre interpréter une série d'octets comme contenant un caractère Unicodé spécifique et pouvoir le restituer dans l'interface. Un texte peut être correctement codé et présenté, mais a toujours des petits carrés car les polices installées ne possèdent tout simplement pas ces caractères. Certains fichiers de polices prennent en charge un large éventail de points de code Unicode (appelés polices pan-Unicode). Mais il y a un maximum: les polices TrueType (les plus populaires de Windows) peuvent stocker jusqu'à 65535 glyphes. La police «Arial» normale contient 3988 glyphes, la variante «Arial Unicode MS» en a 50377. Mais si vous souhaitez imprimer votre poésie en vieux Permic ou en Elbasan, vous devrez installer une police spécifique à cet effet.

Annexe: UTF-8, une étude de cas technique

Avez-vous déjà rencontré le personnage à au milieu d'un mot? Par exemple, il existe une valeur de dimension “José”. Alors, bien sûr, quelqu'un a pu vouloir écrire Josà un roman portugais qui a immédiatement reçu un droit d'auteur avec le sigle du copyright ©. Mais plus probablement, il s'agit d'un encodage erroné. Regardons cet exemple de plus près au niveau du bit.

Les deux octets représentés ici à © sont xC3 et xA9. Épelé en bits:

encodage fichier 4

Supposons que c'est l'UTF-8 qui est utilisé pour coder les caractères Unicode. UTF-8 stocke les 127 premiers points de code (ainsi, les caractères numérotés de 0 à 127) dans le premier octet, le premier bit étant mis à 0. Le premier bit de à est égal à 1, il ne s'agit donc pas d'un caractère de 1 octet. Si le nombre de points de code est plus grand, l'octet suivant est également utilisé. Mais comment?

Le graphique suivant montre la disposition des octets UTF-8. Même si un octet supplémentaire fournit 8 bits supplémentaires, ils ne peuvent pas tous être utilisés pour stocker le point de code (le numéro du caractère Unicode de la table Unicode). Dans une représentation de 1 octet, le premier bit est zéro et 7 correspondent aux points de code, qui sont les xxxx du graphique.

encodage fichier 5

Si vous utilisez plus d'octets, le premier bit est défini sur 1, suivi du bit 0. En fait, le nombre de 1 au début de l'octet n ° 1 correspond au nombre d'octets utilisés pour ce point de code. De plus, pour indiquer que les octets suivants ne sont que cela, ils commencent par 10 dans les deux premiers bits. Donc, cela ne laisse en réalité que 4 bits supplémentaires si un deuxième octet est utilisé. Plutôt décevant, mais il n’y a vraiment aucune solution. Ensuite, pour chaque octet supplémentaire, 5 bits supplémentaires sont activés pour Code Point Duty. Le plus grand point de code que vous pouvez stocker dans la combinaison UTF-8 à 4 octets est x10FFFF, soit 1 114 111 en décimal et le maximum actuel pour Unicode. Cependant, on peut imaginer à quoi ressemblerait un nombre encore plus grand sur 5 octets. Bien que l'architecture ait une limite, avec chaque bit supplémentaire, le nombre maximal double.

Maintenant, revenons à Ã ©. Nous pouvons maintenant faire correspondre les 3 premiers bits du premier et les 2 premiers bits du deuxième octet. Cela pourrait très bien être un numéro UTF-8 à 2 octets.

encodage fichier 6

Très probablement, lors de la lecture de ce fichier, le codage a été défini sur «latin1» au lieu de «utf-8». Cela signifie que le point de code lui-même serait 11 avec 101001, ce qui correspond à xE9 ou 233 décimal. Ce nombre dans la liste Unicode signifie é.  Alors “José” devient "José". Logique…