Что это за повреждение набора символов? (ISO-2022?)

Question

У меня есть текстовый файл из устаревшего источника, содержащий поврежденные символы.

Сначала я думал, что искажение — просто абракадабра, но при более внимательном рассмотрении оказалось, что часть искаженного текста, вероятно, можно восстановить.

Чтобы сосредоточить усилия, было бы полезно понять, как выглядел оригинал, даже если я не смогу его полностью реконструировать.

К сожалению, документ из коллекции, которой я не могу свободно поделиться, но вот фрагмент. Сообщение было преобразовано в UTF-8, но преобразование где-то дало сбой, поэтому оно в основном неразборчиво. Видны фрагменты текста на чешском языке, где акцентированные чешские символы были заменены кириллическими символами (которые, вероятно, были чем-то совершенно другим до преобразования).

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

Я смутно предполагаю, что кодировка может быть связана сИСО-2022, но я недостаточно хорошо с ним знаком, чтобы быть уверенным. Очевидно, что он прошел как минимум через один сломанный фильтр, возможно, через несколько, прежде чем оказался таким.

Если посмотреть на первую строку, d1 93это ѓ, и, вероятно, это был один 8-битный байт до преобразования. За общим шаблоном, похоже, следует ~XFFсигнальный байт, где FF — это некая шестнадцатеричная последовательность в простом ASCII (в основном 83 здесь, но обычно от 80 до 9E во всем образце), а последний байт теперь является символом UTF-8. (Конечно, это могло быть и несколько байтов во входных данных.) Эта последовательность появляется между словами (всегда ~X83ѓ?), а иногда и внутри слов.

Вот тот же фрагмент, но в виде текста, как он теперь отображается в кодировке 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

У меня есть и другие примеры на других языках, поэтому разобраться с чешским — не моя задача. Вот начало одного, не знаю, наверное, на каком-то дальневосточном языке?

 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^?~

(Знаки ^?: — это буквальные символы DEL, ASCII 0x7F.)

Пробел вместо тильды в начале может быть намеком на то, что пошло не так при конвертации, но это всего лишь смелые домыслы.

ESC % 0выглядит как код ISO-2022 для «обозначения другой системы кодирования», но что 0здесь означает? Я, вероятно, слишком туп, чтобы понять статью Википедии без дополнительных примеров, а все остальное, что я смог найти, похоже, очень сосредоточено на каком-то подмножестве, таком как ISO-2022-JP.

Имеет ли смысл мой анализ до сих пор? Можете ли вы помочь мне разобраться в том, что произошло, и, возможно, даже дать совет, как обратить вспять коррупцию?

Я разместил шестнадцатеричные дампы расширенных фрагментов этих двух примеров наhttp://pastebin.com/ffn7CtdG

Answer 1

В этом ответе я подробно излагаю свои идеи относительно источника этих файлов. Это не полный ответ, поскольку более подробный криминалистический анализ требует практического доступа хотя бы к некоторому подмножеству полных файлов.

Некоторые моменты, которые поразили меня в увиденных мною фрагментах:

1. Слова на чешском языке.
2. Между словами существуют странные последовательности, и они часто повторяются.
3. Эти странные последовательности состоят из символов UTF-8, которые не имеют никакого смысла, за исключением того, что некоторые из них по своей природе являются кириллическими.

Я пришел к выводу, что изначально эти файлы не были текстовыми, а были ошибочно преобразованы в UTF-8, как если бы они были текстом, с использованием кодовой страницы, содержащей кириллические символы.

Например, вездесущая последовательность d193— это кириллическая буквамаленький гжечьи различные представления кодовой страницы следующие:

Это дает нам список возможных кодировок исходных файлов, которые зависят от исходных операционных систем. Если они были созданы на компьютере с Windows, их исходная кодовая страница, вероятно, была Windows-1251, но на Mac они, вероятно, были в Macintosh Cyrillic. Конечно, также вполне возможно, что перевод в UTF-8 использовал неправильную кодировку.

Например, мы находим последовательность SPT~X83..Telecom. Компания "SPT Telecom" - это не что иное, как чешская национальная телекоммуникационная компания, основанная в 1993 году, присутствие которой в тексте новостной ленты Reuters вполне логично. Однако нет никаких причин для какого-либо разделителя рядом с пробелом между двумя словами.

Мое объяснение этим загадочным строкам, которые повторяются среди слов, заключается в том, что они не были и не могли быть частью текста. Я считаю, что они, должно быть, были двоичными символами, помещенными между словами, которые, вероятно, имели некоторую связь с форматированием файлов. Поэтому программа конвертации, которая преобразовала файлы в UTF-8, слепо преобразовала их в символы UTF-8, которые не имеют смысла.

Даже пытаясь преобразовать эти последовательности в двоичный код, используя любую из кодовых страниц в списке выше, я не получаю никаких осмысленных последовательностей. Однако у меня есть опыт работы с текстовыми файлами, полученными из некоторых старых текстовых редакторов, которые помещали в текст «невидимые» символы, целью которых было не отображение, а управление отображением.

Я считаю, что это объяснение этих файлов, но я не знаю этот странный формат файла. Это мог быть какой-то неизвестный чешский текстовый редактор (по крайней мере, неизвестный мне). Если файлы можно будет просканировать на предмет дат, содержащихся в тексте, это может помочь сузить круг возможностей.

Я не верю в вашу теорию о том, что исходные файлы хорошо сконструированы и закодированы вИСО-2022, поскольку эти странные последовательности, похоже, не являются (и никогда не являлись) управляющими последовательностями ISO-2022.