¿Qué es esta corrupción del conjunto de caracteres? (¿ISO-2022?)

Question

Tengo un archivo de texto de una fuente heredada que contiene caracteres corruptos.

Al principio pensé que la corrupción era simplemente una palabrería, pero tras un examen más detenido, parece que parte del texto corrupto probablemente podría reconstruirse.

Para centrar mis esfuerzos, sería útil comprender cómo era el original, incluso si no puedo reconstruirlo por completo.

Desafortunadamente, el documento pertenece a una colección que no puedo compartir libremente, pero aquí hay un fragmento. El mensaje se convirtió a UTF-8, pero la conversión falló en alguna parte, por lo que es prácticamente ilegible. Se ven fragmentos de texto en checo, donde los caracteres checos acentuados han sido reemplazados por caracteres cirílicos (que probablemente eran algo completamente diferente antes de la conversión).

0001f80: 33d1 936e 6576 79d1 87d0 bd7a 656e d18c  3..nevy....zen..
0001f90: 6368 7e58 3833 d193 7e58 3945 d19b d0b1  ch~X83..~X9E....
0001fa0: 646f 7374 d0bd 7e58 3833 d193 6e61 7e58  dost..~X83..na~X
0001fb0: 3833 d193 7ad1 87d0 bd7a 656e 20d0 bd7e  83..z....zen ..~
0001fc0: 5838 33d1 936e 6562 6f7e 5838 33d1 9370  X83..nebo~X83..p
0001fd0: d187 656b 6cd0 b164 6b75 7e58 3833 d193  ..ekl..dku~X83..
0001fe0: 7465 6c65 666f 6e6e d0bd 7e58 3833 d193  telefonn..~X83..
0001ff0: 7374 616e 6963 657e 5838 33d1 9376 207e  stanice~X83..v ~
0002000: 5838 33d1 9372 6567 696f 6e75 7e58 3833  X83..regionu~X83
0002010: d193 5072 6168 617e 5838 33d1 9365 7669  ..Praha~X83..evi
0002020: 6475 6a65 7e58 3833 d193 5350 547e 5838  duje~X83..SPT~X8
0002030: 33d1 9354 656c 6563 6f6d 2e7e 5838 33d1  3..Telecom.~X83.
0002040: 934e 617e 5838 33d1 9364 6e65 7e58 2039  .Na~X83..dne~X 9
0002050: 41d1 996e d0bd 7e58 3833 d193 7469 736b  A..n..~X83..tisk
0002060: 6f76 d0b9 7e58 3833 d193 6b6f 6e66 6572  ov..~X83..konfer
0002070: 656e 6369 7e58 3833 d193 746f 7e58 3833  enci~X83..to~X83
0002080: d193 d187 656b 6c7e 5838 33d1 93d1 8765  ....ekl~X83....e

Estoy especulando vagamente que la codificación podría estar relacionada conISO-2022, pero no estoy lo suficientemente familiarizado con él para estar realmente seguro. Obviamente ha pasado por al menos un filtro roto, posiblemente varios, antes de terminar así.

Mirando la primera línea, d1 93es ѓ y probablemente era un solo byte de 8 bits antes de la conversión. Un patrón general parece ser ~XFFseguido por un byte de señal, donde el FF es una secuencia hexadecimal en ASCII simple (principalmente 83 aquí, pero generalmente del 80 al 9E en toda la muestra), y el byte final es ahora un carácter UTF-8. . (Por supuesto, también podrían haber sido varios bytes en la entrada). Esta secuencia aparece entre palabras (¿siempre ~X83ѓ?) y, a veces, dentro de las palabras.

Aquí está el mismo fragmento como solo texto, tal como se representa ahora en UTF-8.

3ѓnevyчнzenьch~X83ѓ~X9Eћбdostн~X83ѓna~X83ѓzчнzen н~X83ѓnebo
~X83ѓpчeklбdku~X83ѓtelefonnн~X83ѓstanice~X83ѓv ~X83ѓregionu
~X83ѓPraha~X83ѓeviduje~X83ѓSPT~X83ѓTelecom.~X83ѓNa~X83ѓdne~
X 9Aљnн~X83ѓtiskovй~X83ѓkonferenci~X83ѓto~X83ѓчekl~X83ѓчe

Tengo otras muestras en otros idiomas, por lo que resolver el checo no es realmente mi objetivo. Aquí está el comienzo de uno en, no sé, ¿probablemente algún idioma del Lejano Oriente?

 X1B%0 ~XD0^?~X98^?~XD0^?^?^?~X82^?~XD0^?~XB5^?^?~X80^?^?~X84^?~XD0^?~XB0^?~XD0
^?^?^?~X81^? ~XD0^?~XB1^?^?~X83^?~XD0^?^?~XD0^?~XB2^?~XD0^?~XB0^?~XD0^?^?^?~X8C
^?~XD0^?^?~XD0^?~XBE^? ~XD0^?~XB7^?~XD0^?~XB0^? ~XD0^?^?~XD0^?~XB5^?^?~X81^?~XD
0^?^?~XD0^?~XBE^?~XD0^?^?^?~X8C^?~XD0^?^?~XD0^?~XBE^? ~XD0^?^?~XD0^?~XB8^?~XD0^
?^?^?~X83^?^?~X82^? ~XD0^?~XB4^?~XD0^?~XBE^? ^?~X81^?~

(Los ^?:s son caracteres DEL literales, ASCII 0x7F).

El espacio en lugar de una tilde al principio podría ser una pista de lo que salió mal en la conversión, pero esto es una especulación descabellada.

ESC % 0parece el código ISO-2022 para "designar otro sistema de codificación", pero ¿qué significa 0aquí? Probablemente soy demasiado tonto para entender el artículo de Wikipedia sin más ejemplos, y todo lo demás que pude encontrar parece muy centrado en algún subconjunto como ISO-2022-JP.

¿Mi análisis hasta ahora tiene sentido para usted? ¿Puedes ayudarme a descubrir qué pasó y tal vez incluso ofrecerme consejos sobre cómo revertir la corrupción?

He publicado volcados hexadecimales de fragmentos extendidos de estos dos ejemplos enhttp://pastebin.com/ffn7CtdG

Answer 1

En esta respuesta detallo mis ideas sobre el origen de estos archivos. Esta no es una respuesta completa, ya que un análisis forense más detallado requiere acceso práctico a al menos un subconjunto de archivos completos.

Algunos puntos que me llaman la atención en los fragmentos que he visto:

1. Las palabras están en checo.
2. Hay secuencias extrañas separando las palabras y se repiten mucho.
3. Estas extrañas secuencias están compuestas de caracteres UTF-8 que no tienen ningún sentido, excepto que algunos de ellos son de naturaleza cirílica.

Mi conclusión es que estos archivos no eran originalmente archivos de texto, sino que se convirtieron erróneamente a UTF-8 como si fueran texto, utilizando una página de códigos que contenía caracteres cirílicos.

Por ejemplo, la secuencia omnipresente de d193es la letra cirílica.pequeño gjecuyas diferentes representaciones de páginas de códigos son:

Esto nos da una lista de posibles codificaciones de los archivos originales, que dependen de los sistemas operativos originales. Si se crearon en una computadora con Windows, su página de códigos original probablemente era Windows-1251, pero en una Mac probablemente estaban en cirílico Macintosh. Por supuesto, también es muy posible que la traducción a UTF-8 haya utilizado una codificación incorrecta.

Por ejemplo, encontramos la secuencia SPT~X83..Telecom. La empresa "SPT Telecom" no es otra cosa que la empresa nacional checa de telecomunicaciones, fundada en 1993, cuya presencia en un texto de Reuters es bastante lógica. Sin embargo, no hay ningún motivo para utilizar separadores además de un espacio en blanco entre las dos palabras.

Mi explicación a estas enigmáticas cadenas que se repiten entre las palabras es que no eran ni podían ser parte del texto. Creo que debieron ser caracteres binarios colocados entre las palabras, lo que probablemente tenía alguna conexión con el formato de los archivos. Por lo tanto, el programa de conversión que convirtió los archivos a UTF-8 los convirtió ciegamente a caracteres UTF-8 que no tienen sentido.

Incluso al intentar convertir estas secuencias a binarias, utilizando cualquiera de las páginas de códigos de la lista anterior, no obtengo ninguna secuencia significativa. Sin embargo, tengo experiencia con archivos de texto provenientes de algunos editores de texto antiguos que colocaban caracteres "invisibles" en el texto cuyo propósito nunca fue mostrarse, sino controlar la visualización.

Creo que esta es la explicación de estos archivos, pero no conozco este extraño formato de archivo. Podría haber sido algún editor de texto checo desconocido (al menos desconocido para mí). Si los archivos se pueden escanear en busca de fechas contenidas en el texto, esto podría ayudar a reducir las posibilidades.

No creo en su teoría de que los archivos originales estén bien construidos y codificados enISO-2022, ya que estas extrañas secuencias no parecen ser (o nunca han sido) secuencias de control ISO-2022.