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

Question

Eu tenho um arquivo de texto de uma fonte legada que contém caracteres corrompidos.

A princípio, achei que a corrupção era apenas um embusteiro, mas, após um exame mais detalhado, parece que alguns dos textos corrompidos provavelmente poderiam ser reconstruídos.

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

Infelizmente, o documento é de uma coleção que não posso compartilhar livremente, mas aqui está um trecho. A mensagem foi convertida em UTF-8, mas a conversão falhou em algum lugar, portanto, é ilegível. Fragmentos de texto em tcheco são visíveis, 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 vagamente especulando que a codificação pode estar relacionada a ISO-2022 , mas eu não estou familiarizado o suficiente para realmente ter certeza. Ele obviamente passou por pelo menos um filtro quebrado, possivelmente vários, antes de acabar assim.

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

Aqui está o mesmo fragmento de apenas texto, já que ele renderiza em UTF-8 agora.

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

Eu tenho outros exemplos em outros idiomas, então não é realmente o foco colocar o checo em ordem. Aqui está o começo de um, eu não sei, provavelmente 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 começo pode ser uma pista do que deu errado na conversão, mas isso é uma especulação selvagem.

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

A 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?

Eu postei lixeiras hexagonais de fragmentos estendidos desses dois exemplos no link

    

Answer 1

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

Alguns pontos que me atingem nos fragmentos que vi:

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

Minha conclusão é que esses arquivos não eram originalmente arquivos de texto, mas estavam 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ílica small gje cujas diferentes representações de página de código são :

Issonosdáumalistadepossíveiscodificaçõesdosarquivosoriginais,quedependemnossistemasoperacionaisoriginais.SeelesforamcriadosemumcomputadorcomWindows,suapáginadecódigooriginaleraprovavelmenteoWindows-1251,masemumMacelesprovavelmenteemMacintoshcirílico.Claro,tambéméinteiramentepossívelqueatraduçãoparaOUTF-8usouacodificaçãoerrada.

Porexemplo,encontramosaseqüênciaSPT~X83..Telecom.Aempresa"SPT Telecom" não é mais do que a Empresa de telecomunicações nacional checa, fundada em 1993, cuja presença em um texto do Reuters newswire é bastante lógico. No entanto, não há motivo para nenhum separador ao lado de um espaço em branco. entre as duas palavras.

Minha explicação para essas cordas intrigantes que se repetem entre as palavras é que elas não eram e não poderiam ser parte do texto. Eu acredito que eles devem ter sido então caracteres binários colocados entre as palavras, que provavelmente tinham alguma conexão para a formatação dos arquivos. O programa de conversão que converteu os arquivos para UTF-8, portanto, converteu-os cegamente para caracteres UTF-8 que não fazem sentido.

Mesmo tentando converter essas seqüências para binário, usando qualquer uma das páginas de código no acima da lista, não obtenho sequências significativas. No entanto, tenho experiência com texto arquivos vindos de alguns editores de texto antigos que colocavam caracteres "invisíveis" no texto cuja finalidade nunca seria exibida, mas sim controlar a exibição.

Eu acredito que esta é a explicação para esses arquivos, mas eu não sei disso estranho formato de arquivo. Poderia ter sido algum editor de texto checo desconhecido (pelo menos desconhecido para mim). Se os arquivos puderem ser verificados quanto às datas contidas no texto, isso pode ajudar a diminuir as possibilidades.

Eu não acredito em sua teoria de que os arquivos originais sejam bem construídos e codificado em ISO-2022 , uma vez que estas sequências estranhas não parecem ser (ou nunca foram) ISO -2022 seqüências de controle.