Dans quel jeu de caractères 8 bits est 0x9d significatif?

Question

Dans quel jeu de caractères de type ASCII 8 bits pour l'anglais est 0x9d significatif? Je nettoie certains anciens fichiers de données et, à l'occasion, trouve un 0x9d dans du texte autrement ASCII. (Non, ce n'est pas UTF-8.)

Ce n'est pas valide dans Windows-1252. Le codec Python "latin-1" le convertit en Unicode 0x9D, qui est "Operating System Command". Cela n'a pas de sens. En Unicode, vous obtenez une boîte avec [009d]. (En Python, vous pouvez convertir n'importe quoi en Latin-1 sans élever les erreurs, mais cela ne signifie pas que cela soit significatif.)

Exemples, avec des échappements de type Python, provenant d'une base de données désordonnée que je nettoie up qui combine le texte provenant de nombreuses sources:

Guitar Pro, JamPlay, RedBana\\\'s Audition,\x9d Doppleganger\x99s The Lounge\x9d or Heatwave Interactive\x99s Platinum Life Country,\\" 

for example \\"I\\\'ve seen the bull run in Pamplona, Spain\x9d.\\" Everything 

Netwise Depot is a \\"One Stop Web Shop\\"\x9d that provides sustainable \\"green\\"\x9d living 

are looking for a \\"Do It for Me\\"\x9d solution 

Dans le contexte, je suspecterais ™ ou ®. Mais quel est le code 8 bits?

Answer 1

En Windows-1256, utilisé pour les locales en arabe, \x99 est un signe de marque déposée et \x9d est un non-jointeur de largeur zéro. Cela semble plausible dans les positions énumérées, bien que redondant probablement. Il n'y a certainement pas de pénurie de character sets à essayer.

Un outil pour tenter de deviner automatiquement est chardet.

Answer 2

Peut être les données proviennent d'un fichier DOS (CP850). Dans mon expérience dans ce cas, le caractère 0x9D a été utilisé comme un signe de "diamètre" lorsqu'il s'agit de tuyaux ou de tubes.

Answer 3

est ici une hypothèse tout à fait sauvage:

Certains avant système (vraiment cassé) travaillant sur ces données tenté d'écrire chaque caractère UTF-8, mais en fait seulement écrit le dernier octet de chaque séquence (peut-être eu un tampon un octet bizarre quelque part). Sinon, il était en UTF-8 dans le passé, mais quelqu'un qui l'a vu dans un encodage différent a fait une recherche-et-remplacer pour supprimer les octets 0xE2 0x80 parce qu'ils "n'appartiennent pas" et n'ont pas réalisé que le reste " caractère spécial "n'était pas celui qu'ils voulaient non plus.

ASCII, serait bien sûr, être transmis à travers son encodage UTF-8 serait d'un octet long. La «MARQUE DE COTATION UNIQUE» (U + 2019) ’ est codée en UTF-8 avec les octets 0xE2 0x80 0x99. Les endroits où vous avez \x99s est ce qui m'a fait aller dans cette voie, puisque l'apostrophe devant un s serait souvent traduite par une citation droite dans un logiciel de traitement de texte populaire. Si seulement le dernier octet du personnage était enregistré, vous auriez juste le 0x99 là. La «MARQUE DE COTATION DOUBLE DROITE» (U + 201D) ” est codée en UTF-8 avec les octets 0xE2 0x80 0x9D. Le 0x9D que vous avez dans votre texte est souvent à la fin d'une chaîne entre guillemets. Et, il est souvent juste à côté d'un guillemet simple et régulier. Je me demande si quelqu'un a essayé de faire une sorte de passe de nettoyage préalable sur les données, et a réussi à remettre dans la citation de fermeture, mais a laissé le "bizarre" 0x9D là-dedans. Comme je l'ai dit, c'est une hypothèse folle, mais s'il s'agit d'un conglomérat de données provenant de divers systèmes anciens, il est difficile de savoir exactement ce qui peut lui être arrivé. Le dernier octet de UTF-8 était juste l'encodage anglais "normal" le plus proche que je pourrais trouver qui aurait quelque chose de raisonnable dans le texte anglais et inclus les octets que vous cherchiez.

Answer 4

Je vais fermer cela, car, après avoir demandé à plusieurs endroits, il est clair qu'il n'y a pas de codage de données ASCII 8 bits étendu qui utilise 0x9D d'une manière qui a du sens ici.

Cela peut être le résultat d'une longue confusion sur les données. Il existe d'autres questions Stack Overflow sur les conversions charset Python qui échouent sur 0x9D spécifiquement, donc ce n'est pas unique à ces données. Quelque part, il y a quelque chose qui colle dans un 0x9D de temps en temps, généralement après des guillemets. Peut-être un vieux traitement de texte. Merci tout le monde.