Как исправить кодировку-фигурный Апостроф отображается как ‰Ûª

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

don‰Ûªt

в hex байты 64 6f 6e 89 db aa 74. Очевидно, почти наверняка, что ‰Ûª должен быть фигурным Апострофом, возможно U+02BC,U+2019 или U+0092. [редактировать, чтобы добавить: основываясь на копировании правильного Апострофа из PDF-файла, содержащего тот же текст, я теперь достаточно уверен это U+2019.]

этот сайт говорит

Если последовательность бит не имеет смысла (для человека) в любой кодировке, документ скорее всего был неправильно конвертированы в какой-то момент. ... Если документ неверно истолкован и преобразован в другую кодировку, он не работает. Попытка "восстановить" его может или не может быть успешной, обычно это не так. Любое ручное переключение битов или другая кодировка вуду в основном это, вуду.

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

2
задан user1310503
10.02.2023 8:58 Количество просмотров материала 3571
Распечатать страницу

1 ответ

может кто-нибудь сказать мне, как работать, как файл поврежден ...

Я не могу, но, возможно, Вам ПОВЕЗЕТ.

учитывая зашифрованную конфигурацию Куба Рубика, очень легко разработать набор ходов, чтобы вернуть его в исходное состояние. Обычно невозможно определить, какие ходы были использованы для достижения скремблированного состояния , потому что количество возможных последовательностей ходов огромно.

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

0x89 не является допустимым первым байтом для трехбайтовой кодировки UTF8 символа. 0xDBAA арабский пустой центр низкой остановки. Что, конечно, неправдоподобно. Возможно, UTF8 был неверно истолкован как некоторая 8-битная кодировка, а затем сохранен как другая 8-битная кодировка. Если файл был рядом с Японией, вы можете бросить некоторые злоупотребления JIS, Shift-JIS и EUC в смесь.

есть, возможно, десяток правдоподобных символов Юникода и, вероятно, большее количество правдоподобных 8-битных и 16-битных кодировок. Слишком много перестановок, чтобы попробовать вручную. Если бы это было достаточно важно, я бы, возможно, написал код, чтобы попробовать все перестановки начального символа плюс два скремблирования и посмотреть, прибудут ли они в 0x89DBAA.

  1. создать текстовый файл UTF8 без BOM (рекомендуется консорциумом Unicode).
  2. прочитайте этот файл с помощью блокнота MS-Windows в локали" Windows-Latin-1". Блокнот неправильно UTF8 как CP-1252, отчасти потому, что UTF-8 не имеет знака порядка байтов и потому, что много инструментов Майкрософт злоупотребляют / злоупотребляют меткой байт-заказа как Индикатор кодирования.
  3. сохранить файл как "Unicode". Блокнот использует неправильную терминологию Microsoft, и переводит что он думает, это CP-1252 в UTF-16 little-endian (с BOM)

но это слишком просто (я не пробовал).

Я уверен, что ответ будет стало очевидным в ретроспективе. Но сейчас это небольшое утешение.

... и как это исправить?

учитывая, что раскрывается только содержание английского слова don't мы можем сделать вывод, что все данные 95% ASCII. То делает если возможный для использования ручного осмотра ...

  1. составьте список всех различных последовательностей gobbledegook и вероятных замен, начиная с 0x89dbaa ->'.

  2. используйте инструмент, ориентированный на байты (например,sed), чтобы сделать эти замены.

  3. ???

  4. профит!

2
отвечен RedGrittyBrick 2023-02-11 16:46

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх