Как расшифровать кодировку закодированных символов: специальная кодировка символов - PullRequest
1 голос
/ 03 января 2012

У меня есть данные в формате CSV, которые были серьезно перемешаны при кодировании символов, вероятно, переходя от одного к другому между различными программными приложениями (LibreOffice Calc, Microsoft, Excel, Google Refine, пользовательское программное обеспечение PHP / MySQL; в Windows XP, Windows 7 и машины GNU / Linux из разных регионов мира ...). Кажется, что где-то в процессе, не-ASCII символы стали серьезно зашифрованными, и я не уверен, как их расшифровать или обнаружить шаблон. Для этого вручную потребуется несколько тысяч записей ...

Вот пример. Для "Trois-Rivières", когда я открываю эту часть файла CSV в Python, он говорит:

Trois-Rivi\xc3\x83\xc2\x85\xc3\x82\xc2\xa0res

Вопрос: через какой процесс я могу обратить

\xc3\x83\xc2\x85\xc3\x82\xc2\xa0

чтобы вернуться

è

т.е. как я могу расшифровать это? Как это могло быть зашифровано в первую очередь? Как я могу восстановить эту ошибку?

Ответы [ 2 ]

3 голосов
/ 31 января 2012

Вы можете проверить решения, которые были предложены в: Двойное декодирование Unicode в Python

Другим более простым решением для перебора является создание таблицы сопоставления между небольшим набором зашифрованных символов с помощью регулярного выражения (((\\\x[a-c0-9]{2}){8})) поиска во входном файле. Для файла из одного источника у вас должно быть меньше 32 для французского и меньше 10 для немецкого. Затем вы можете запустить «найти и заменить», используя эту маленькую таблицу сопоставлений.

2 голосов
/ 28 декабря 2018

Исходя из комментария dan04 выше , мы можем предположить, что буква "è" почему-то была неверно истолкована как "Š", к которой затем применялась кодировка трехкратная UTF-8к нему.

Так как же тогда «è» превратилось в «Š»?Ну, у меня была догадка, что наиболее вероятное объяснение будет между двумя различными 8-битными кодировками, поэтому я посмотрел некоторые кодировки общих символов в Википедии и нашел соответствие: в CP850 (и в различных других связанных 8-битных кодовых страницах DOS , таких как CP851, CP853, CP857 и т. д.) буква "è" кодируется как байт 0x8A, который в Windows-1252 представляет вместо этого «Š».

С этим знанием мы можем воссоздать эту извилистую цепочку неправильных кодировок с помощью простой командной строки оболочки Unix:

$ echo "Trois-Rivières" \
  | iconv -t cp850 \
  | iconv -f windows-1252 -t utf-8 \
  | iconv -f iso-8859-1 -t utf-8 \
  | iconv -f iso-8859-1 -t utf-8 \
  | iconv -f ascii --byte-subst='\x%02X'

Trois-Rivi\xC3\x83\xC2\x85\xC3\x82\xC2\xA0res

Здесь, здесьПервый вызов iconv просто преобразует строку из моей локальной кодировки символов - которая оказывается UTF-8 - в CP850, а последний просто кодирует байты не ASCII с помощью кодов \xNN Python-стиля.Три вызова iconv в середине воссоздают действительные действительные этапы перекодирования , применяемые к данным: сначала с (предполагаемого) Windows-1252 до UTF-8, а затем дважды с ISO-8859-1 доUTF-8.

Так как мы можем это исправить?Что ж, нам просто нужно применить те же шаги в обратном порядке:

$ echo -e 'Trois-Rivi\xC3\x83\xC2\x85\xC3\x82\xC2\xA0res' \
  | iconv -f utf-8 -t iso-8859-1 \
  | iconv -f utf-8 -t iso-8859-1 \
  | iconv -f utf-8 -t windows-1252 \
  | iconv -f cp850

Trois-Rivières

Хорошей новостью является то, что этот процесс должен быть в основном обратимым.Плохая новость заключается в том, что любые буквы «ü», «ì», «Å», «É» и «Ø» в исходном тексте могли быть необратимо искажены, поскольку байты, используемые для кодирования этих букв в CP850, не определены в Windows-1252.(Если вам повезет, они могут быть интерпретированы как те же самые С1 управляющие коды , которые эти байты представляют в ISO-8859-1, и в этом случае обратное преобразование должно быть в принципе возможным.Хотя мне удалось выяснить, как убедить iconv сделать это.)

...