Encodage mystérieux de type UTF-8

Question

On m'a donné un dossier qui est soi-disant en UTF-8, mais il y a des encodages bizarres pour certains des caractères non anglais. Par exemple, dans cet encodage mystérieux, la chaîne Hangul

한국경북영덕군강구면

est codé comme :

0xED959C 0xEAB5AD 0xEAB2BD 0xEBB63F 0xEC983F 0xEB3F95 0xEAB5B0 0xEAB095 0xEAB5AC 0xEBA9B4

(différences en gras) plutôt que le standard UTF-8 :

0xED959C 0xEAB5AD 0xEAB2BD 0xEBB681 0xEC9881 0xEB8D95 0xEAB5B0 0xEAB095 0xEAB5AC 0xEBA9B4 "

Je constate le même phénomène avec les caractères cyrilliques et chinois : certains caractères ont le même codage que l'UTF-8, mais d'autres sont différents. Les caractères déformés ont la même largeur d'octet que les caractères non déformés et j'ai vérifié qu'ils ne font pas partie d'un jeu d'extension. De plus, j'ai déjà vérifié qu'il s'agit de pas Java "Modified UTF-8".

Avez-vous une autre idée de ce que cela peut être ?

BTW : Je n'ai pas accès au code ou aux personnes qui ont écrit le fichier à l'origine.

De plus, je suis sous Mac 10.11.6, au cas où cela aurait un rapport avec la situation.

Answer 1

Votre chaîne d'exemple est constituée d'UTF-8, mais avec certaines valeurs d'octets (à savoir x81 et x8D) remplacées par le point d'interrogation ASCII. ? (x3F). La seule explication plausible est que la chaîne de caractères de votre exemple est passée par un logiciel qui a essayé d'interpréter son contenu selon un autre encodage (probablement un jeu de caractères à un octet), et qui a remplacé les caractères "invalides" par ? (de manière analogue à la façon dont un processeur de texte Unicode pourrait remplacer les caractères Unicode invalides par U+FFFD).

Malheureusement, ce processus n'est pas vraiment réversible, puisqu'au moins deux valeurs d'octets distinctes (et probablement d'autres qui n'apparaissent pas dans votre exemple) ont été remplacées, et qu'il n'y a donc aucun moyen garanti d'identifier la valeur d'octet d'origine dans tous les cas. En fonction de l'importance de ce problème, c'est-à-dire du temps qu'il vaut la peine d'y consacrer, vous pourriez identifier l'ensemble complet des octets qui ont été remplacés, puis écrire quelque chose qui essaie chaque valeur possible pour chaque octet, en comparant les séquences de caractères résultantes avec (disons) les fréquences des bigrammes d'un corpus de texte dans la langue concernée, et en sélectionnant l'octet le plus probable. (Bien sûr, il y aura des erreurs. Pour estimer le taux d'erreur qui en résulte, vous pouvez essayer le même processus sur un fichier connu sous le nom de texte.)