Может кто-нибудь сказать мне, как выяснить, как файл был поврежден, ...
Я не могу, но, возможно, вам повезет.
Учитывая скремблированную конфигурацию кубика Рубика, очень легко отработать набор ходов, чтобы вернуть его в исходное состояние. Обычно невозможно определить, какие ходы использовались, чтобы прийти в зашифрованное состояние - потому что число возможных последовательностей ходов огромно.
Ваша проблема похожа. Частично потому, что вы не даете подсказок о платформах, локалях и инструментах, которые могли быть использованы для создания этого текстового файла.
0x89 не является допустимым первым байтом для трехбайтовой кодировки UTF8 символа. 0xDBAA - арабский пустой центральный нижний стоп. Что, конечно, неправдоподобно.
Возможно, UTF8 был неверно истолкован как некоторая 8-битная кодировка, а затем сохранен как другая 8-битная кодировка. Если файл был рядом с Японией, вы можете добавить в микс некоторые злоупотребления JIS, Shift-JIS и EUC.
Может быть, есть дюжина правдоподобных символов Юникода и, возможно, большее количество вероятных 8-битных и 16-битных кодировок. Это слишком много перестановок, чтобы попробовать вручную. Если бы это было достаточно важно, я, возможно, написал бы код, чтобы попробовать все перестановки начального символа плюс две скремблирования и посмотреть, дойдут ли они до 0x89DBAA.
Статистически я ожидаю, что наиболее вероятный сценарий - это нечто почти, но не совсем отличное:
- Создайте текстовый файл UTF8 без спецификации (как рекомендует консорциум Unicode).
- Прочитайте этот файл с помощью MS-Windows Notepad в локали «Windows-Latin-1».
Блокнот неправильно воспринимает UTF8 как CP-1252, отчасти потому, что UTF-8 не имеет метки порядка байтов и потому что многие инструменты Microsoft злоупотребляют / неправильно используют метку порядка байтов в качестве индикатора кодировки.
- Сохранить файл как "Юникод".
Блокнот использует неверную терминологию Microsoft и переводит то, что он считает CP-1252, в UTF-16 с прямым порядком байтов (с спецификацией)
Но это слишком просто (так что я не пробовал).
Я уверен, что ответ будет ослепительно очевидным в ретроспективе. Но это маленький комфорт сейчас.
... и как это исправить?
Учитывая, что единственным раскрытым контентом является английское слово don't мы не можем сделать вывод, что все данные на 95% ASCII. Это делает возможным использование ручного осмотра ...
Составьте список всех различных последовательностей gobbledegook и вероятных замен, начиная с 0x89dbaa -> ' .
Используйте байтово-ориентированный инструмент (например, sed) для выполнения этих замен.
???
Прибыль!
