Mojibake - Mojibake

L' article Wikipédia japonais codé en UTF-8 pour Mojibake tel qu'il s'affiche s'il est interprété comme un codage Windows-1252

Mojibake (文字化け; IPA :  [mod͡ʑibake] ) est le texte brouillé qui est le résultat du texte décodé à l'aide d'un codage de caractères involontaire . Le résultat est un remplacement systématique des symboles par des symboles sans aucun rapport, souvent issus d'un système d'écriture différent .

Cet affichage peut inclure le caractère de remplacement générique (" ") aux endroits où la représentation binaire est considérée comme invalide. Un remplacement peut également impliquer plusieurs symboles consécutifs, tels qu'ils sont visualisés dans un codage, lorsque le même code binaire constitue un symbole dans l'autre codage. Cela est dû soit à des codages de longueur constante différents (comme dans les codages asiatiques à 16 bits par rapport aux codages européens à 8 bits), soit à l'utilisation de codages à longueur variable (notamment UTF-8 et UTF-16 ).

L'échec du rendu des glyphes en raison de polices manquantes ou de glyphes manquants dans une police est un problème différent qui ne doit pas être confondu avec mojibake. Les symptômes de cet échec de rendu incluent des blocs avec le point de code affiché en hexadécimal ou utilisant le caractère de remplacement générique. Il est important de noter que ces remplacements sont valides et sont le résultat d'une gestion correcte des erreurs par le logiciel.

Étymologie

Mojibake signifie "transformation de personnage" en japonais . Le mot est composé de文字(moji, IPA :  [mod͡ʑi] ), "caractère" et化け(bake, IPA :  [bäke̞] , prononcé "bah-keh"), "transformer".

Causes

Pour reproduire correctement le texte original qui a été encodé, la correspondance entre les données encodées et la notion de son encodage doit être préservée. Comme mojibake est l'exemple de non-conformité entre ceux-ci, il peut être réalisé en manipulant les données elles-mêmes, ou simplement en les réétiquetant.

Mojibake est souvent vu avec des données de texte qui ont été étiquetées avec un mauvais encodage ; il peut même ne pas être étiqueté du tout, mais déplacé entre des ordinateurs avec des encodages par défaut différents. Les protocoles de communication qui reposent sur les paramètres de chaque ordinateur plutôt que sur l'envoi ou le stockage de métadonnées avec les données constituent une source majeure de problèmes .

Les paramètres par défaut différents entre les ordinateurs sont en partie dus aux différents déploiements d' Unicode parmi les familles de systèmes d'exploitation , et en partie aux spécialisations des codages hérités pour les différents systèmes d'écriture des langues humaines. Alors que les distributions Linux sont principalement passées à UTF-8 en 2004, Microsoft Windows utilise généralement UTF-16 et utilise parfois des pages de codes 8 bits pour les fichiers texte dans différentes langues.

Pour certains systèmes d'écriture , un exemple étant le japonais , plusieurs encodages ont historiquement été utilisés, amenant les utilisateurs à voir relativement souvent mojibake. Comme exemple japonais, le mot mojibake "文字化け" stocké sous EUC-JP peut s'afficher de manière incorrecte sous la forme "ﾊｸｻ ｽ､ｱ", "ﾊｸｻ嵂ｽ､ｱ" ( MS-932 ) ou "ﾊｸｻ郾ｽ､ｱ" ( Shift JIS-2004 ). Le même texte stocké en UTF-8 s'affiche sous la forme "譁 蟄怜喧縺 " s'il est interprété comme Shift JIS. Ceci est encore exacerbé si d'autres paramètres régionaux sont impliqués : le même texte UTF-8 apparaît sous la forme "æ–‡å—化ã??'" dans un logiciel qui suppose que le texte est dans les encodages Windows-1252 ou ISO-8859-1 , généralement étiqueté Western, ou (par exemple) comme "鏂囧瓧鍖栥亼" s'il est interprété comme étant dans un paramètre régional GBK (Chine continentale).

Exemple de mojibake
Texte original ?? ?? ?? ??
Octets bruts d'encodage EUC-JP Californie B8 BB FA B2 BD A4 B1
Octets interprétés comme encodage Shift-JIS ?? ?? ?? ?? ?? ?? ??
Octets interprétés comme un codage ISO-8859-1 Ê ?? » ú ² ½ ?? ±
Octets interprétés comme un codage GBK ?? ?? ?? ??

Sous-spécification

Si l'encodage n'est pas précisé, il appartient au logiciel de le décider par d'autres moyens. Selon le type de logiciel, la solution typique est soit la configuration, soit l' heuristique de détection de jeu de caractères . Les deux sont sujets à des erreurs de prédiction dans des scénarios pas si rares.

L'encodage des fichiers texte est affecté par les paramètres régionaux , qui dépendent de la langue de l'utilisateur, de la marque du système d'exploitation et éventuellement d'autres conditions. Par conséquent, l'encodage supposé est systématiquement erroné pour les fichiers qui proviennent d'un ordinateur avec un réglage différent, ou même d'un logiciel localisé différemment au sein du même système. Pour Unicode, une solution consiste à utiliser une marque d'ordre d'octet , mais pour le code source et d'autres textes lisibles par machine, de nombreux analyseurs ne tolèrent pas cela. Une autre consiste à stocker l'encodage en tant que métadonnées dans le système de fichiers. Les systèmes de fichiers qui prennent en charge les attributs de fichier étendus peuvent les stocker au format user.charset. Cela nécessite également un support dans les logiciels qui veulent en profiter, mais ne perturbent pas les autres logiciels.

Alors que quelques encodages sont faciles à détecter, en particulier UTF-8, il y en a beaucoup qui sont difficiles à distinguer (voir détection de jeu de caractères ). Un navigateur Web peut ne pas être en mesure de distinguer une page codée dans EUC-JP et une autre dans Shift-JIS si le schéma de codage n'est pas attribué explicitement à l'aide des en-têtes HTTP envoyés avec les documents, ou à l'aide des balises méta du document HTML qui sont utilisées pour remplacer les en-têtes HTTP manquants si le serveur ne peut pas être configuré pour envoyer les en-têtes HTTP appropriés ; voir les encodages de caractères en HTML .

Mauvaise spécification

Mojibake se produit également lorsque l'encodage est mal spécifié. Cela se produit souvent entre des encodages similaires. Par exemple, le client de messagerie Eudora pour Windows était connu pour envoyer des e-mails étiquetés ISO-8859-1 qui étaient en réalité Windows-1252 . La version Mac OS d'Eudora n'a pas présenté ce comportement. Windows-1252 contient des caractères imprimables supplémentaires dans la plage C1 (les plus fréquemment observés étant les guillemets courbes et les tirets supplémentaires ), qui n'étaient pas affichés correctement dans les logiciels conformes à la norme ISO ; cela affectait particulièrement les logiciels fonctionnant sous d'autres systèmes d'exploitation tels qu'Unix .

Ignorance humaine

Parmi les codages encore utilisés, beaucoup sont partiellement compatibles les uns avec les autres, l' ASCII étant le sous-ensemble commun prédominant. Cela ouvre la voie à l'ignorance humaine :

  • La compatibilité peut être une propriété trompeuse, car le sous-ensemble commun de caractères n'est pas affecté par un mélange de deux encodages (voir Problèmes dans différents systèmes d'écriture ).
  • Les gens pensent qu'ils utilisent l'ASCII et ont tendance à étiqueter n'importe quel sur-ensemble d'ASCII qu'ils utilisent réellement comme "ASCII". Peut-être pour simplifier, mais même dans la littérature académique, le mot "ASCII" peut être utilisé comme exemple de quelque chose de non compatible avec Unicode, où évidemment "ASCII" est Windows-1252 et "Unicode" est UTF-8. Notez que UTF-8 est rétrocompatible avec ASCII.

Surspécification

Lorsqu'il existe des couches de protocoles, chacune essayant de spécifier l'encodage en fonction d'informations différentes, la moindre information peut être trompeuse pour le destinataire. Par exemple, considérons un serveur Web servant un fichier HTML statique sur HTTP. Le jeu de caractères peut être communiqué au client de 3 manières différentes :

  • dans l'en-tête HTTP. Ces informations peuvent être basées sur la configuration du serveur (par exemple, lors de la diffusion d'un fichier hors disque) ou contrôlées par l'application exécutée sur le serveur (pour les sites Web dynamiques).
  • dans le fichier, sous forme de balise méta HTML ( http-equivou charset) ou d' encodingattribut d'une déclaration XML . Il s'agit de l'encodage dans lequel l'auteur voulait enregistrer le fichier particulier.
  • dans le fichier, en tant que marque d'ordre des octets . Il s'agit de l'encodage dans lequel l'éditeur de l'auteur l'a enregistré. À moins qu'une conversion d'encodage accidentelle ne se soit produite (en l'ouvrant dans un encodage et en l'enregistrant dans un autre), ce sera correct. Il n'est cependant disponible que dans les encodages Unicode tels que UTF-8 ou UTF-16.

Manque de support matériel ou logiciel

Un matériel beaucoup plus ancien est généralement conçu pour prendre en charge un seul jeu de caractères et le jeu de caractères ne peut généralement pas être modifié. La table de caractères contenue dans le micrologiciel de l'affichage sera localisée pour avoir des caractères pour le pays dans lequel l'appareil doit être vendu, et généralement la table diffère d'un pays à l'autre. En tant que tels, ces systèmes afficheront potentiellement mojibake lors du chargement de texte généré sur un système d'un autre pays. De même, de nombreux premiers systèmes d'exploitation ne prennent pas en charge plusieurs formats d'encodage et finiront donc par afficher mojibake s'ils sont conçus pour afficher du texte non standard - les premières versions de Microsoft Windows et Palm OS, par exemple, sont localisées pays par pays et ne prend en charge les normes de codage pertinentes pour le pays dans lequel la version localisée sera vendue et affichera mojibake si un fichier contenant un texte dans un format de codage différent de celui de la version que le système d'exploitation est conçu pour prendre en charge est ouvert.

Résolutions

Les applications utilisant UTF-8 comme codage par défaut peuvent atteindre un plus grand degré d'interopérabilité en raison de son utilisation généralisée et de sa rétrocompatibilité avec US-ASCII . UTF-8 a également la capacité d'être directement reconnu par un algorithme simple, de sorte qu'un logiciel bien écrit devrait pouvoir éviter de mélanger UTF-8 avec d'autres encodages.

La difficulté de résoudre une instance de mojibake varie en fonction de l'application dans laquelle elle se produit et de ses causes. Deux des applications les plus courantes dans lesquelles mojibake peut se produire sont les navigateurs Web et les traitements de texte . Les navigateurs et les traitements de texte modernes prennent souvent en charge un large éventail de codages de caractères. Les navigateurs permettent souvent à un utilisateur de modifier le paramètre d'encodage de son moteur de rendu à la volée, tandis que les traitements de texte permettent à l'utilisateur de sélectionner l'encodage approprié lors de l'ouverture d'un fichier. Cela peut prendre quelques essais et erreurs pour que les utilisateurs trouvent le bon encodage.

Le problème se complique lorsqu'il se produit dans une application qui ne prend normalement pas en charge un large éventail de codages de caractères, comme dans un jeu informatique non Unicode. Dans ce cas, l'utilisateur doit modifier les paramètres d'encodage du système d'exploitation pour qu'ils correspondent à ceux du jeu. Cependant, la modification des paramètres d'encodage à l'échelle du système peut également entraîner Mojibake dans les applications préexistantes. Dans Windows XP ou version ultérieure, un utilisateur a également la possibilité d'utiliser Microsoft AppLocale , une application qui permet de modifier les paramètres régionaux par application. Même ainsi, la modification des paramètres d'encodage du système d'exploitation n'est pas possible sur les systèmes d'exploitation antérieurs tels que Windows 98 ; pour résoudre ce problème sur les systèmes d'exploitation antérieurs, un utilisateur devrait utiliser des applications de rendu de polices tierces.

Problèmes dans différents systèmes d'écriture

Anglais

Mojibake dans les textes anglais apparaît généralement dans la ponctuation, comme les tirets cadratin (—), les tirets en (–) et les guillemets bouclés (",",','), mais rarement dans le texte de caractères, car la plupart des encodages sont d'accord avec l' ASCII sur le codage de l' alphabet anglais . Par exemple, le signe dièse "£" apparaîtra sous la forme "£" s'il a été codé par l'expéditeur en UTF-8 mais interprété par le destinataire en tant que CP1252 ou ISO 8859-1 . Si itéré en utilisant CP1252, cela peut conduire à "£", "£", "ÃÆ'‚£", etc.

Certains ordinateurs, à des époques plus anciennes, disposaient d'encodages spécifiques au fournisseur, ce qui provoquait également une incompatibilité pour le texte anglais. Les ordinateurs 8 bits de la marque Commodore utilisaient l' encodage PETSCII , particulièrement remarquable pour l'inversion des majuscules et des minuscules par rapport à l' ASCII standard . Les imprimantes PETSCII fonctionnaient bien sur d'autres ordinateurs de l'époque, mais renversaient la casse de toutes les lettres. Les mainframes IBM utilisent le codage EBCDIC qui ne correspond pas du tout à l'ASCII.

Autres langues d'Europe occidentale

Les alphabets des langues germaniques du nord , catalan , finnois , allemand , français , portugais et espagnol sont tous des extensions de l' alphabet latin . Les caractères supplémentaires sont généralement ceux qui sont corrompus, rendant les textes légèrement illisibles avec mojibake :

… et leurs équivalents en majuscules, le cas échéant.

Ce sont des langues pour lesquelles le jeu de caractères ISO-8859-1 (également connu sous le nom de Latin 1 ou Western ) a été utilisé. Cependant, ISO-8859-1 a été obsolète par deux normes concurrentes, la rétrocompatible Windows-1252 et l' ISO-8859-15 légèrement modifiée . Les deux ajoutent le signe euro € et le français œ, mais sinon toute confusion de ces trois jeux de caractères ne crée pas de mojibake dans ces langues. De plus, il est toujours sûr d'interpréter ISO-8859-1 comme Windows-1252, et assez sûr de l'interpréter comme ISO-8859-15, en particulier en ce qui concerne le signe Euro, qui remplace le signe monétaire rarement utilisé (¤) . Cependant, avec l'avènement de l' UTF-8 , mojibake est devenu plus courant dans certains scénarios, par exemple l'échange de fichiers texte entre les ordinateurs UNIX et Windows , en raison de l'incompatibilité d'UTF-8 avec Latin-1 et Windows-1252. Mais UTF-8 a la capacité d'être directement reconnu par un algorithme simple, de sorte qu'un logiciel bien écrit devrait pouvoir éviter de mélanger UTF-8 avec d'autres encodages, donc c'était plus courant lorsque beaucoup avaient des logiciels ne prenant pas en charge UTF-8. La plupart de ces langues étaient prises en charge par le CP437 par défaut de MS-DOS et d'autres codages par défaut de la machine, à l'exception de l'ASCII, de sorte que les problèmes lors de l'achat d'une version du système d'exploitation étaient moins fréquents. Cependant, Windows et MS-DOS ne sont pas compatibles.

En suédois, norvégien, danois et allemand, les voyelles sont rarement répétées, et c'est généralement évident lorsqu'un caractère est corrompu, par exemple la deuxième lettre de « körlek » ( kärlek , « amour »). De cette façon, même si le lecteur doit deviner entre å, ä et ö, presque tous les textes restent lisibles. Le texte finnois, en revanche, comporte des voyelles répétées dans des mots comme hääyö (« nuit de noces ») qui peuvent parfois rendre le texte très difficile à lire (par exemple, hääyö apparaît comme « hÃ⁠¤Ã⁠¤yÃ⁠¶ »). L'islandais et le féroïen ont respectivement dix et huit caractères confondants, ce qui peut donc rendre plus difficile la devinette des caractères corrompus ; Des mots islandais comme þjóðlöð (« hospitalité exceptionnelle ») deviennent presque entièrement inintelligibles lorsqu'ils sont rendus par « ¾jóðlöð ».

En allemand, Buchstabensalat (« salade de lettres ») est un terme courant pour ce phénomène, et en espagnol, deformación (littéralement déformation).

Certains utilisateurs translittèrent leur écriture lorsqu'ils utilisent un ordinateur, soit en omettant les signes diacritiques problématiques, soit en utilisant des remplacements de digraphes (å → aa, ä/æ → ae, ö/ø → oe, ü → ue etc.). Ainsi, un auteur peut écrire « ueber » au lieu de « über », ce qui est une pratique courante en allemand lorsque les trémas ne sont pas disponibles. Cette dernière pratique semble mieux tolérée dans la sphère linguistique allemande que dans les pays nordiques . Par exemple, en norvégien, les digrammes sont associés au danois archaïque et peuvent être utilisés pour plaisanter. Cependant, les digrammes sont utiles dans la communication avec d'autres parties du monde. À titre d'exemple, le joueur de football norvégien Ole Gunnar Solskjær avait son nom épelé "SOLSKJAER" sur son dos lorsqu'il jouait pour Manchester United .

Un artefact d' UTF-8 mal interprété comme ISO-8859-1 , " Ring meg nÃ¥" (" Ring meg nå "), a été vu dans une escroquerie par SMS faisant rage en Norvège en juin 2014.

Exemples
Exemple suédois : Smörgås ( sandwich ouvert )
Encodage de fichier Paramétrage dans le navigateur Résultat
MS-DOS 437 ISO 8859-1 Sm"rg†s
ISO 8859-1 Mac Romain SmˆrgÂs
UTF-8 ISO 8859-1 Smörgès
UTF-8 Mac Romain Smörgås

Europe centrale et orientale

Les utilisateurs de langues d' Europe centrale et orientale peuvent également être touchés. Étant donné que la plupart des ordinateurs n'étaient connectés à aucun réseau du milieu à la fin des années 1980, il existait des codages de caractères différents pour chaque langue avec des caractères diacritiques (voir ISO/IEC 8859 et KOI-8 ), variant souvent également selon le système d'exploitation.

hongrois

Le hongrois est une autre langue affectée, qui utilise les 26 caractères anglais de base, plus les formes accentuées á, é, í, ó, ú, ö, ü (tous présents dans le jeu de caractères Latin-1), plus les deux caractères ő et ű , qui ne sont pas en Latin-1. Ces deux caractères peuvent être correctement encodés en Latin-2, Windows-1250 et Unicode. Avant qu'Unicode ne devienne courant dans les clients de messagerie, les e-mails contenant du texte hongrois avaient souvent les lettres ő et corrompues, parfois au point d'être méconnaissables. Il est courant de répondre à un e-mail rendu illisible (voir les exemples ci-dessous) par un caractère mutilant (appelé "betűszemét", qui signifie "lettre poubelle") avec la phrase "Árvíztűrő tükörfúrógép", une phrase absurde (littéralement "Flood- perceuse à miroir résistante") contenant tous les caractères accentués utilisés en hongrois.

Exemples
Encodage source Encodage cible Résultat Occurrence
exemple hongrois RVÍZTŰRŐ TÜKÖRFÚRÓGÉP
árvíztűrő tükörfúrógép 		Les caractères en rouge sont incorrects et ne correspondent pas à l'exemple en haut à gauche.
CP 852 CP 437 ╡ RV ╓ ZT δ R è TÜKÖRF Θ R α GÉP
árvízt √ r ï tükörfúrógép 		C'était très courant à l'époque du DOS lorsque le texte était encodé par le codage CP 852 d'Europe centrale ; cependant, le système d'exploitation , un logiciel ou une imprimante utilisait le codage par défaut CP 437 . Veuillez noter que les lettres minuscules sont principalement correctes, à l'exception de ő (ï) et ű (√). Ü/ü est correct car CP 852 a été rendu compatible avec l'allemand. De nos jours, cela se produit principalement sur les ordonnances et les chèques imprimés.
CWI-2 CP 437 Å RV ì ZT ÿ R º TÜKÖRF ù R ò GÉP
árvízt û r ô tükörfúrógép 		L' encodage CWI-2 a été conçu pour que le texte reste assez lisible même si l'écran ou l'imprimante utilise l' encodage CP 437 par défaut . Cet encodage a été largement utilisé dans les années 1980 et au début des années 1990, mais de nos jours, il est complètement obsolète.
Windows-1250 Windows-1252 RVÍZT Û R Õ TÜKÖRFÚRÓGÉP
árvízt û r õ tükörfúrógép 		L'encodage Windows occidental par défaut est utilisé à la place de celui d'Europe centrale. Seuls ő-Ő (õ-Õ) et ű-Ű (û-Û) sont faux, mais le texte est parfaitement lisible. C'est l'erreur la plus courante de nos jours; en raison de l'ignorance, cela se produit souvent sur les pages Web ou même dans les médias imprimés.
CP 852 Windows-1250 μ RV Ö ZT de R © T de K ™ RF de R Ŕ G ?? P
rv ztűr < t ?? k " rf £ r ˘ g , p 		L'encodage Windows d'Europe centrale est utilisé à la place de l'encodage DOS. L'utilisation de est correcte.
Windows-1250 CP 852 ┴ RV ═ ZT █ R Ň T ▄ K Í RF ┌ R Ë G ╔ P
ß vr Ý ztűr § t Ø k ÷ rf ˙ r g Ú p 		L'encodage DOS d'Europe centrale est utilisé à la place de l'encodage Windows. L'utilisation de est correcte.
Devis-imprimable ASCII 7 bits =C1 RV =CD ZT =DB R =D5 T =DC K =D6 RF =DA R =D3 G =C9 P
=E1 rv =ED zt =FB r =F5 t =FC k =F6 rf =FA r =F3 g = E9 p 		Principalement causé par des serveurs de messagerie mal configurés, mais peut également se produire dans les messages SMS sur certains téléphones portables.
UTF-8 Windows-1252 Ã ??RV Ã ??ZT ° R Å ?? T AOE K × RF en tant que R Ã » G Ã ‰ P
á vr à zt Å ± r Å » t ü k ¶ rf º r ó g à © p 		Principalement causé par des services Web ou des clients de messagerie Web mal configurés, qui n'ont pas été testés pour une utilisation internationale (car le problème reste caché pour les textes anglais). Dans ce cas, le contenu réel (souvent généré) est en UTF-8 ; cependant, il n'est pas configuré dans les en- têtes HTML , donc le moteur de rendu l'affiche avec l'encodage occidental par défaut.

polonais

Avant la création d' ISO 8859-2 en 1987, les utilisateurs de diverses plates-formes informatiques utilisaient leurs propres encodages de caractères tels que AmigaPL sur Amiga, Atari Club sur Atari ST et Masovia, IBM CP852 , Mazovia et Windows CP1250 sur les PC IBM. Les sociétés polonaises vendant les premiers ordinateurs DOS ont créé leurs propres moyens mutuellement incompatibles d'encoder les caractères polonais et ont simplement reprogrammé les EPROM des cartes vidéo (généralement CGA , EGA ou Hercules ) pour fournir des pages de codes matériels avec les glyphes nécessaires pour le polonais—situés arbitrairement sans référence à l'endroit où d'autres vendeurs d'ordinateurs les avaient placés.

La situation a commencé à s'améliorer lorsque, après la pression de groupes d'universitaires et d'utilisateurs, ISO 8859-2 est devenu la « norme Internet » avec une prise en charge limitée des logiciels des fournisseurs dominants (aujourd'hui largement remplacé par Unicode). Avec les nombreux problèmes causés par la variété des codages, même aujourd'hui, certains utilisateurs ont tendance à se référer aux caractères diacritiques polonais comme krzaczki ([kshach-kih], lit. "petits arbustes").

Alphabets russes et autres alphabets cyrilliques

Mojibake peut être appelé familièrement krakozyabry ( кракозя́бры [krɐkɐˈzʲæbrɪ̈] ) en russe , qui était et reste compliqué par plusieurs systèmes d'encodage cyrillique . L' Union soviétique et la première Fédération de Russie ont développé des codages KOI ( Kod Obmena Informatsiey , Код Обмена Информацией , qui se traduit par « Code for Information Exchange »). Cela a commencé avec le KOI7 7 bits uniquement en cyrillique , basé sur l' ASCII mais avec le latin et quelques autres caractères remplacés par des lettres cyrilliques. Puis vint l'encodage KOI8 8 bitsqui est une extension ASCII qui encode les lettres cyrilliques uniquement avec des octets de poids fort correspondant aux codes 7 bits de KOI7. C'est pour cette raison que le texte KOI8, même russe, reste partiellement lisible après avoir supprimé le huitième bit, ce qui était considéré comme un avantage majeur à l'ère dessystèmes de messagerie 8BITMIME inconscients. Par exemple, les mots " Школа русского языка " shkola russkogo yazyka , encodés dans KOI8 puis passés par le processus de suppression de bits élevés, finissent par être rendus comme " [KOLA RUSSKOGO qZYKA ". Finalement, KOI8 a gagné des saveurs différentes pour le russe et le bulgare ( KOI8-R ), l'ukrainien ( KOI8-U ), le biélorusse (KOI8-RU) et même le tadjik (KOI8-T).

Pendant ce temps, en Occident, la page de code 866 supportait l' ukrainien et le biélorusse ainsi que le russe/ bulgare dans MS-DOS . Pour Microsoft Windows , la page de code 1251 a ajouté la prise en charge du serbe et d' autres variantes slaves du cyrillique .

Plus récemment, l' encodage Unicode inclut des points de code pour pratiquement tous les caractères de toutes les langues du monde, y compris tous les caractères cyrilliques.

Avant Unicode, il était nécessaire de faire correspondre l'encodage du texte avec une police utilisant le même système d'encodage. Ne pas le faire produisait un charabia illisible dont l'apparence spécifique variait en fonction de la combinaison exacte de l'encodage du texte et de l'encodage des polices. Par exemple, si vous essayez d'afficher du texte cyrillique non Unicode à l'aide d'une police limitée à l'alphabet latin ou à l'aide du codage par défaut (« occidental »), résulte généralement un texte composé presque entièrement de voyelles avec des signes diacritiques. (KOI8 " Библиотека " ( biblioteka , library) devient " âÉÂÌÉÏÔÅËÁ ".) L'utilisation de la page de codes Windows 1251 pour afficher le texte dans KOI8 ou vice versa produit un texte brouillé composé principalement de lettres majuscules (KOI8 et la page de codes 1251 partagent la même région ASCII, mais KOI8 a des lettres majuscules dans la région où la page de codes 1251 a des minuscules, et vice versa). En général, le charabia cyrillique est symptomatique de l'utilisation de la mauvaise police cyrillique. Au cours des premières années du secteur russe du World Wide Web, KOI8 et la page de code 1251 étaient courants. En 2017, on peut encore rencontrer des pages HTML dans la page de code 1251 et, rarement, des encodages KOI8, ainsi qu'Unicode. (On estime que 1,7% de toutes les pages Web dans le monde - toutes langues incluses - sont encodées dans la page de code 1251.) Bien que la norme HTML inclut la possibilité de spécifier l'encodage pour n'importe quelle page Web donnée dans sa source, cela est parfois négligé, forçant l'utilisateur pour changer manuellement les encodages dans le navigateur.

En bulgare , le mojibake est souvent appelé majmunica ( маймуница ), ce qui signifie « [alphabet] du singe ». En serbe , on l'appelle bre ( ђубре ), signifiant " poubelle ". Contrairement à l'ex-URSS, les Slaves du Sud n'ont jamais utilisé quelque chose comme KOI8, et la page de code 1251 était le codage cyrillique dominant avant Unicode. Par conséquent, ces langues ont connu moins de problèmes d'incompatibilité d'encodage que le russe. Dans les années 1980, les ordinateurs bulgares utilisaient leur propre encodage MIK , qui est superficiellement similaire (bien qu'incompatible avec) CP866.

Exemple
Exemple russe : Кракозябры ( krakozyabry , caractères poubelles)
Encodage de fichier Paramétrage dans le navigateur Résultat
MS-DOS 855 ISO 8859-1 á ÆÖóÞ¢áñ
KOI8-R ISO 8859-1 'ÒÁËÏÚÑÂÒÙ
UTF-8 KOI8-R я─п╟п╨п╬п╥я▐п╠я─я▀

Langues yougoslaves

Le croate , le bosniaque , le serbe (les dialectes de la langue yougoslave serbo-croate ) et le slovène ajoutent à l'alphabet latin de base les lettres š, đ, č, ć, ž, et leurs homologues majuscules Š, Đ, Č, Ć, Ž ( seulement č/Č, š/Š et ž/Ž en slovène ; officiellement, bien que d'autres soient utilisés en cas de besoin, principalement dans les noms étrangers). Toutes ces lettres sont définies en Latin-2 et Windows-1250 , alors que seules certaines (š, Š, ž, Ž, Đ) existent dans le système d'exploitation habituel Windows-1252 , et sont là à cause d'autres langues.

Bien que Mojibake puisse apparaître avec n'importe lequel de ces caractères, les lettres qui ne sont pas incluses dans Windows-1252 sont beaucoup plus sujettes aux erreurs. Ainsi, même de nos jours, "šđčćž ŠĐČĆŽ" est souvent affiché comme "šðèæž ŠÐÈÆŽ", bien que ð, è, æ, È, Æ ne soient jamais utilisés dans les langues slaves.

Lorsqu'ils sont limités à l'ASCII de base (la plupart des noms d'utilisateur, par exemple), les remplacements courants sont : selon la casse du mot). Tous ces remplacements introduisent des ambiguïtés, de sorte que la reconstruction de l'original à partir d'un tel formulaire est généralement effectuée manuellement si nécessaire.

L' encodage Windows-1252 est important car les versions anglaises du système d'exploitation Windows sont les plus répandues, et non les versions localisées. Les raisons en sont un marché relativement petit et fragmenté, augmentant le prix d'une localisation de haute qualité, un degré élevé de piratage de logiciels (à son tour causé par le prix élevé des logiciels par rapport aux revenus), qui décourage les efforts de localisation, et les personnes préférant les versions anglaises de Windows et d'autres logiciels.

La volonté de différencier le croate du serbe, le bosniaque du croate et du serbe, et maintenant même le monténégrin des trois autres, crée de nombreux problèmes. Il existe de nombreuses localisations différentes, utilisant des normes différentes et de qualité différente. Il n'y a pas de traductions communes pour la grande quantité de terminologie informatique originaire de l'anglais. En fin de compte, les gens utilisent des mots anglais adoptés ("kompjuter" pour "ordinateur", "kompajlirati" pour "compiler", etc.) à faire en fonction de la phrase traduite. Par conséquent, les personnes qui comprennent l'anglais, ainsi que celles qui sont habituées à la terminologie anglaise (qui le sont le plus, car la terminologie anglaise est également principalement enseignée dans les écoles à cause de ces problèmes) choisissent régulièrement les versions anglaises originales des logiciels non spécialisés.

Lorsque l'écriture cyrillique est utilisée (pour le macédonien et partiellement le serbe ), le problème est similaire à celui des autres écritures cyrilliques .

Les versions plus récentes de Windows anglais permettent de modifier la page de codes (les versions plus anciennes nécessitent des versions anglaises spéciales avec cette prise en charge), mais ce paramètre peut être et a souvent été mal défini. Par exemple, Windows 98 et Windows Me peuvent être configurés sur la plupart des pages de codes à un octet qui ne s'écrivent pas de droite à gauche, y compris 1250, mais uniquement au moment de l'installation.

Langues caucasiennes

Les systèmes d'écriture de certaines langues de la région du Caucase , notamment les écritures géorgienne et arménienne , peuvent produire du mojibake. Ce problème est particulièrement aigu dans le cas de ArmSCII ou ARMSCII, un ensemble de codages de caractères obsolètes pour l'alphabet arménien qui ont été remplacés par les normes Unicode. ArmSCII n'est pas largement utilisé en raison d'un manque de soutien dans l'industrie informatique. Par exemple, Microsoft Windows ne le prend pas en charge.

Encodages asiatiques

Un autre type de mojibake se produit lorsque le texte est analysé par erreur dans un codage multi-octets, tel que l'un des codages pour les langues d'Asie de l'Est . Avec ce type de mojibake, plus d'un (généralement deux) caractères sont corrompus à la fois, par exemple "k舐lek" ( kärlek ) en suédois, où " är " est analysé comme " 舐 ". Par rapport au mojibake ci-dessus, il est plus difficile à lire, car des lettres sans rapport avec le problème å, ä ou ö manquent, et est particulièrement problématique pour les mots courts commençant par å, ä ou ö tels que "än" (qui devient "舅"). Puisque deux lettres sont combinées, le mojibake semble également plus aléatoire (plus de 50 variantes par rapport aux trois normales, sans compter les majuscules plus rares). Dans de rares cas, une chaîne de texte entière qui comprend un modèle de longueurs de mots particulières, comme la phrase « Bush a caché les faits », peut être mal interprétée.

Japonais

Article principal: langue japonaise et ordinateurs

En japonais , le phénomène est, comme mentionné, appelé mojibake (文字化け) . C'est un problème particulier au Japon en raison des nombreux encodages différents qui existent pour le texte japonais. Outre les encodages Unicode comme UTF-8 et UTF-16, il existe d'autres encodages standard, tels que Shift-JIS (machines Windows) et EUC-JP (systèmes UNIX). Mojibake, en plus d'être rencontré par les utilisateurs japonais, est également souvent rencontré par des non-japonais lorsqu'ils tentent d'exécuter un logiciel écrit pour le marché japonais.

Chinois

En chinois , le même phénomène est appelé Luàn mǎ ( Pinyin , chinois simplifié 乱码, chinois traditionnel 亂碼, signifiant « code chaotique ») et peut se produire lorsque le texte informatisé est encodé dans un seul codage de caractères chinois mais s'affiche avec le mauvais codage. Lorsque cela se produit, il est souvent possible de résoudre le problème en changeant le codage des caractères sans perte de données. La situation est compliquée en raison de l'existence de plusieurs systèmes d'encodage de caractères chinois en usage, les plus courants étant : Unicode , Big5 et Guobiao (avec plusieurs versions rétrocompatibles), et la possibilité d'encoder des caractères chinois à l'aide d'un codage japonais.

Il est facile d'identifier l'encodage d'origine lorsque luanma apparaît dans les encodages Guobiao :

Encodage d'origine Vu comme Résultat Texte original Noter
Gros5 FR ? T瓣в变巨肚 ?? Caractères chinois brouillés sans aucune trace de sens original. Le caractère rouge n'est pas un point de code valide dans GB2312.
Maj-JIS FR ?? ?? Kana est affiché sous forme de caractères avec le radical 亻, tandis que les kanji sont d'autres caractères. La plupart d'entre eux sont extrêmement rares et peu utilisés en chinois moderne.
EUC-KR FR 抛农聪墨 테크니카 Caractères chinois simplifiés courants aléatoires qui, dans la plupart des cas, n'ont aucun sens. Facilement identifiable grâce aux espaces entre plusieurs caractères.

Un problème supplémentaire se produit lorsque les encodages manquent de caractères, ce qui est courant avec les caractères rares ou obsolètes qui sont encore utilisés dans les noms de personnes ou de lieux. Des exemples de cela sont les politiciens taïwanais Wang Chien-shien (chinois :王建煊; pinyin : Wáng Jiànxuān )'s "煊", Yu Shyi-kun (chinois simplifié :游锡堃; chinois traditionnel :游錫堃; pinyin : Yóu Xíkūn )'s "堃" et le "喆" du chanteur David Tao (chinois:陶喆; pinyin: Táo Zhé ) manquant dans Big5 , le "镕" de l' ancien premier ministre de la RPC Zhu Rongji (chinois:朱镕基; pinyin: Zhū ​​Róngjī ) manquant dans GB2312 , symbole de copyright "©" manquant dans GBK .

Les journaux ont traité ce problème de diverses manières, notamment en utilisant un logiciel pour combiner deux personnages similaires existants ; en utilisant une image de la personnalité ; ou simplement en substituant un homophone au caractère rare dans l'espoir que le lecteur serait en mesure de faire la déduction correcte.

Texte indien

Un effet similaire peut se produire dans les écritures brahmiques ou indiennes d' Asie du Sud , utilisées dans des langues indo-aryennes ou indiennes comme l' hindoustani (hindi-ourdou), le bengali , le pendjabi , le marathi et d'autres, même si le jeu de caractères utilisé est correctement reconnu par L'application. En effet, dans de nombreux scripts indiens, les règles selon lesquelles les symboles de lettres individuelles se combinent pour créer des symboles de syllabes peuvent ne pas être correctement comprises par un ordinateur dépourvu du logiciel approprié, même si les glyphes des formes de lettres individuelles sont disponibles.

Un exemple de ceci est l'ancien logo Wikipedia , qui tente de montrer le caractère analogue à « wi ​​» (la première syllabe de « Wikipédia ») sur chacune des nombreuses pièces du puzzle. La pièce du puzzle destinée à porter le caractère Devanagari pour « wi ​​» affichait plutôt le caractère « wa » suivi d'une voyelle modificatrice « i » non appariée , facilement reconnaissable en tant que mojibake généré par un ordinateur non configuré pour afficher du texte indien. Le logo repensé en mai 2010 a corrigé ces erreurs.

L'idée du texte brut nécessite que le système d'exploitation fournisse une police pour afficher les codes Unicode. Cette police est différente d'OS à OS pour Singhala et elle crée des glyphes orthographiquement incorrects pour certaines lettres (syllabes) sur tous les systèmes d'exploitation. Par exemple, le 'reph', la forme abrégée de 'r' est un signe diacritique qui va normalement au-dessus d'une lettre simple. Cependant, il est faux d'ajouter des lettres comme « ya » ou « la » dans des contextes spécifiques. Pour les mots ou noms sanscrits hérités des langues modernes, tels que कार्य, IAST : kārya , ou आर्या, IAST : āryā , il est possible de le mettre au-dessus de ces lettres. En revanche, pour des sons similaires dans les langues modernes qui résultent de leurs règles spécifiques, il n'est pas mis en tête, comme le mot करणाऱ्या, IAST : karaṇāryā , forme radicale du mot commun करणारा/री, IAST : karaṇārā/rī , en langue marathi . Mais cela se produit dans la plupart des systèmes d'exploitation. Cela semble être un défaut de programmation interne des polices. Sous Mac OS et iOS, la combinaison muurdhaja l (l sombre) et 'u' et sa forme longue donnent toutes deux des formes erronées.

Certains scripts Indic et dérivés d'Indic, notamment Lao , n'étaient pas officiellement pris en charge par Windows XP avant la sortie de Vista . Cependant, divers sites ont créé des polices à télécharger gratuitement.

birman

En raison des sanctions occidentales et de l'arrivée tardive de la prise en charge de la langue birmane dans les ordinateurs, une grande partie de la première localisation birmane a été produite localement sans coopération internationale. Le moyen dominant de prise en charge du birman est via la police Zawgyi , une police qui a été créée en tant que police Unicode mais n'était en fait que partiellement compatible Unicode. Dans la police Zawgyi, certains points de code pour l'écriture birmane ont été implémentés comme spécifié dans Unicode , mais d'autres ne l'étaient pas. Le Consortium Unicode appelle cela des encodages de polices ad hoc . Avec l'avènement des téléphones mobiles, les fournisseurs de services mobiles tels que Samsung et Huawei ont simplement remplacé les polices système compatibles Unicode par des versions Zawgyi.

En raison de ces encodages ad hoc , les communications entre les utilisateurs de Zawgyi et d'Unicode seraient rendues sous forme de texte brouillé. Pour contourner ce problème, les producteurs de contenu publieraient des messages à la fois en Zawgyi et en Unicode. Le gouvernement du Myanmar a désigné le 1er octobre 2019 comme "U-Day" pour passer officiellement à Unicode. La transition complète devrait prendre deux ans.

Langues africaines

Dans certains systèmes d'écriture d'Afrique , le texte non codé est illisible. Les textes susceptibles de produire du mojibake incluent ceux de la Corne de l'Afrique, tels que l' écriture Ge'ez en Éthiopie et en Érythrée , utilisée pour l' amharique , le tigré et d'autres langues, et la langue somalienne , qui utilise l' alphabet Osmanya . En Afrique australe , l' alphabet Mwangwego est utilisé pour écrire les langues du Malawi et l' alphabet Mandombe a été créé pour la République démocratique du Congo , mais ceux-ci ne sont généralement pas pris en charge. Divers autres systèmes d'écriture originaires d' Afrique de l'Ouest présentent des problèmes similaires, tels que l' alphabet N'Ko , utilisé pour les langues mandingues en Guinée , et le syllabaire Vai , utilisé au Libéria .

arabe

Une autre langue affectée est l' arabe (voir ci - dessous ). Le texte devient illisible lorsque les encodages ne correspondent pas.

Exemples

Encodage de fichier Paramétrage dans le navigateur Résultat
Exemple arabe : ( Déclaration universelle des droits de l'homme )
Rendu du navigateur : الإعلان العالمى لحقوق الإنسان
UTF-8 Windows-1252 الإعلان العالمى Ù„Øقوق الإنسان
KOI8-R ©ь╖ы└ь╔ь╧ы└ь╖ы├ ь╖ы└ь╧ь╖ы└ы┘ы┴ ы└ь╜ы┌ы┬ы┌ ь╖ы└ь╔ы├ьЁь ??
ISO 8859-5 иЇй иЅиЙй иЇй иЇй иЙиЇй й й й ий й й иЇй иЅй иГиЇй
CP 866 е╪╣┘Д╪з┘Ж ╪з┘Д╪╣╪з┘Д┘Е┘Й ┘Д╪н┘В┘И┘В ╪з┘Д╪е┘Ж╪ ??
ISO 8859-6 ع ظ ظ ع ظ ع ظ ع ظ ظ ع ع ع ع ظع ع ع ظ ع ظ ع
ISO 8859-2 ا٠ؼؚ٠ا٠ا٠ؚا٠٠٠٠Ř٠٠٠ا٠ؼ٠ساŮ
Windows-1256 Windows-1252 ÇáÅÚáÇä ÇáÚÇáãì áÍÞæÞ ÇáÅäÓÇä

Les exemples de cet article n'ont pas UTF-8 comme paramètre de navigateur, car UTF-8 est facilement reconnaissable, donc si un navigateur prend en charge UTF-8, il devrait le reconnaître automatiquement et ne pas essayer d'interpréter autre chose comme UTF-8.

Voir également

  • Point de code
  • Caractère de remplacement
  • Caractère de remplacement
  • Nouvelle ligne – Les conventions de représentation du saut de ligne diffèrent entre les systèmes Windows et Unix. Bien que la plupart des logiciels prennent en charge les deux conventions (ce qui est trivial), les logiciels qui doivent préserver ou afficher la différence (par exemple , les systèmes de contrôle de version et les outils de comparaison de données ) peuvent devenir considérablement plus difficiles à utiliser s'ils n'adhèrent pas à une convention.
  • Marque octet de poids - Le plus intrabande moyen de stocker le codage ainsi que les données - faites -le précéder. Ceci est intentionnellement invisible pour les humains utilisant un logiciel conforme, mais sera par conception perçu comme des "caractères inutiles" pour un logiciel non conforme (y compris de nombreux interprètes ).
  • Entités HTML - Un codage de caractères spéciaux en HTML, la plupart du temps facultatif, mais requis pour que certains caractères échappent à l' interprétation en tant que balisage.

    Bien que le fait de ne pas appliquer cette transformation soit une vulnérabilité (voir scripts intersites ), l'appliquer trop souvent entraîne la confusion de ces caractères. Par exemple, le guillemet "devient &quot;, &amp;quot;, &amp;amp;quot;et ainsi de suite.

  • Bush a caché les faits

Les références

Liens externes

  • La définition du dictionnaire de mojibake sur Wiktionnaire
  • Médias liés à Mojibake sur Wikimedia Commons