O que é essa corrupção do conjunto de caracteres? (ISO-2022?)

O que é essa corrupção do conjunto de caracteres? (ISO-2022?)

Tenho um arquivo de texto de uma fonte herdada que contém caracteres corrompidos.

A princípio pensei que a corrupção fosse apenas uma bobagem, mas, após um exame mais detalhado, parece que parte do texto corrompido provavelmente poderia ser reconstruído.

Para concentrar os meus esforços, seria útil compreender como era o original, mesmo que não consiga reconstruí-lo completamente.

Infelizmente, o documento pertence a uma coleção que não posso compartilhar livremente, mas aqui está um trecho. A mensagem foi convertida para UTF-8, mas a conversão falhou em algum lugar, por isso está praticamente ilegível. São visíveis fragmentos de texto em tcheco, onde os caracteres tchecos acentuados foram substituídos por caracteres cirílicos (que provavelmente eram algo completamente diferente antes da conversão).

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

Estou especulando vagamente que a codificação pode estar relacionada aISO-2022, mas não estou familiarizado o suficiente com ele para ter certeza. Obviamente, passou por pelo menos um filtro quebrado, possivelmente vários, antes de terminar assim.

Olhando para a primeira linha, d1 93é ѓ e provavelmente era um único byte de 8 bits antes da conversão. Um padrão geral parece ser ~XFFseguido por um byte de sinal, onde o FF é alguma sequência hexadecimal em ASCII simples (principalmente 83 aqui, mas geralmente de 80 a 9E em toda a amostra), e o byte final agora é um caractere UTF-8 . (Poderia ter sido vários bytes na entrada também, é claro.) Essa sequência aparece entre palavras (sempre ~X83ѓ?) e às vezes dentro de palavras.

Aqui está o mesmo fragmento apenas de texto, conforme agora é renderizado em 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

Tenho outros exemplos em outros idiomas, então resolver o tcheco não é realmente meu foco. Aqui está o início de um, não sei, provavelmente em alguma língua do Extremo 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^?~

(Os ^?:s são caracteres DEL literais, ASCII 0x7F.)

O espaço no lugar de um til no início pode ser uma dica sobre o que deu errado na conversão, mas isso é especulação selvagem.

ESC % 0se parece com o código ISO-2022 para "designar outro sistema de codificação", mas o que significa 0aqui? Provavelmente sou muito denso para entender o artigo da Wikipedia sem mais exemplos, e tudo o mais que pude encontrar parece muito focado em algum subconjunto como ISO-2022-JP.

Minha análise até agora faz sentido para você? Você pode me ajudar a descobrir o que aconteceu e talvez até oferecer conselhos sobre como reverter a corrupção?

Publiquei dumps hexadecimais de fragmentos estendidos desses dois exemplos emhttp://pastebin.com/ffn7CtdG

Responder1

Nesta resposta detalho minhas idéias sobre a origem desses arquivos. Esta não é uma resposta completa, uma vez que uma análise forense mais detalhada requer acesso prático a pelo menos algum subconjunto de arquivos completos.

Alguns pontos que me chamam a atenção nos fragmentos que vi:

  1. As palavras estão em tcheco
  2. Existem sequências estranhas separando as palavras e elas se repetem muito
  3. Essas sequências estranhas são compostas de caracteres UTF-8 que não fazem nenhum sentido, exceto que alguns deles são de natureza cirílica.

Minha conclusão é que esses arquivos não eram originalmente arquivos de texto, mas foram erroneamente convertidos para UTF-8 como se fossem texto, usando uma página de código que continha caracteres cirílicos.

Por exemplo, a sequência onipresente de d193é a letra cirílicapequeno gjecujas diferentes representações de página de código são:

imagem

Isso nos dá uma lista de possíveis codificações dos arquivos originais, que dependem dos sistemas operacionais originais. Se eles foram criados em um computador Windows, sua página de código original provavelmente era Windows-1251, mas em um Mac eles provavelmente estavam em cirílico Macintosh. Claro, também é perfeitamente possível que a tradução para UTF-8 tenha usado a codificação errada.

Por exemplo, encontramos a sequência SPT~X83..Telecom. A empresa "SPT Telecom" nada mais é do que a empresa nacional checa de telecomunicações, fundada em 1993, cuja presença num texto noticioso da Reuters é bastante lógica. No entanto, não há razão para qualquer separador além de um espaço em branco entre as duas palavras.

Minha explicação para essas sequências intrigantes que se repetem entre as palavras é que elas não faziam, e não poderiam fazer, parte do texto. Acredito que devem ter sido então caracteres binários colocados entre as palavras, o que provavelmente tinha alguma ligação com a formatação dos arquivos. O programa de conversão que converteu os arquivos para UTF-8 os converteu cegamente para caracteres UTF-8 que não fazem sentido.

Mesmo tentando converter essas sequências em binário, usando qualquer uma das páginas de código da lista acima, não obtenho nenhuma sequência significativa. Porém, tenho experiência com arquivos de texto provenientes de alguns editores de texto antigos que colocavam caracteres "invisíveis" no texto cujo objetivo nunca foi ser exibido, mas sim controlar a exibição.

Acredito que esta seja a explicação para esses arquivos, mas não conheço esse estranho formato de arquivo. Poderia ter sido algum editor de texto tcheco desconhecido (pelo menos desconhecido para mim). Se os arquivos puderem ser verificados em busca de datas contidas no texto, isso poderá ajudar a restringir as possibilidades.

Não acredito na sua teoria de que os arquivos originais sejam bem construídos e codificados emISO-2022, uma vez que essas sequências estranhas não parecem ser (ou nunca foram) sequências de controle ISO-2022.

informação relacionada