Обратное распространение неправильно (двойного) закодированного CSV
У меня есть файл CSV, который кто-то неправильно закодировал.
Файл представляет собой базу данных фильмов с соответствующими актерами. Я скачал его, чтобы попрактиковаться в кодировании так называемого числа Бэкона.
Это выглядит так:
movieId,title,actors
(...)
61,Eye for an Eye (1996),(a ton of other actors)|Dolores VelÌÁzquez|(more actors)
59,The Confessional (1995),(a ton of other actors)|Richard Fr̩chette|Fran̤ois Papineau|Marie Gignac|Normand Daneau|Anne-Marie Cadieux|Suzanne Cl̩ment|Lynda Beaulieu|Pascal Rollin|Billy Merasty|Paul H̩bert|Marthe Turgeon|Adreanne Lepage-Beaulieu|Andr̩e-Anne Th̩roux-Faille|Rodrigue Proteau|Philippe Paquin|Pierre H̩bert|Nathalie D'Anjou|Danielle Fichaud|Jules Philip|Jacques Laroche|Claude-Nicolas Demers|Jean-Philippe C̫t̩|Tristan Wiseman|Marc-Olivier Tremblay|Jacques Brouillet|Jean-Paul L'Allier|Denis Bernard|Ren̩e Hudon|Serge Laflamme|Carl Mathieu
(...)
Теперь, как видите, вместо умлаутов и букв с ударениями (ÄÖÜ, É, À, Û и т. д.) у актеров вместо умлаутов используются комбинации других специальных символов.
Благодаря очень полезному ответу на этот вопрос мы установили, что это действительно случай Моджибаке.
Моя цель — программно исправить неработающие символы, декодируя и кодируя их в правильном порядке.
Попытка переосмыслить «обычные» ошибки не привела к какой-либо комбинации, дающей этот конкретный результат, но это определенно похоже на традиционную проблему «байты UTF-8 были неправильно декодированы с помощью 8-битной кодировки». Я просто не знаю, что такое 8-битная кодировка.
Спасибо, @MartinBrown, я добавил в пост еще несколько примеров.
Похоже, что 8-битная кодировка Иоахим говорит об отображении Ì для байта 0xc3. К сожалению, я не использую здесь 8-битную кодировку...
Если количество проблемных последовательностей ограничено, возможно, вам лучше просто жестко запрограммировать «таблицу исправлений».
@JoachimSauer, спасибо, это тоже была моя первоначальная идея. Проблема в том, что CSV очень большой (тысячи длинных строк), и его невозможно проверить вручную. Итак, есть некоторые очень специфические случаи, такие как перевернутый восклицательный знак, которые встречаются 1–3 раза. Я случайно заметил этот восклицательный знак, но могут быть и другие случаи, которые я бы пропустил. Если они закодированы тремя символами, я неправильно закодирую два из них (М плюс следующий за ним) вместо полного, создавая еще больше новых проблем. Поэтому я бы хотел избежать такой таблицы.
Вы столкнулись с двойным случаем моджибаке (пример на Python): 'FrÌ©chette|Fran̤ois'.encode( 'cp1252').decode( 'mac-romanian').encode( 'cp1252').decode( 'utf-8') возвращает 'Fréchette|François'. Пожалуйста, отредактируйте свой вопрос, чтобы улучшить минимально воспроизводимый пример. В частности, расскажите, откуда взялся файл csv (т. е. как он создается), а также как вы его читаете…
Я предполагаю, что один из вариантов — взять правильные образцы необработанного текста и применить к нему каждую пару преобразований символьных страниц, которые вы можете придумать, и надеяться, что одно из них даст вам Ì для байта 0xc3 и, следовательно, будет совпадением. В противном случае я думаю, что идея @Joachim Sauers, вероятно, имеет наибольшую вероятность успеха (даже если вам придется делать это несколько раз, когда выявляются новые, нечастые неисправности). Я подозреваю, что странный случай невозможно исправить.
@JosefZ большое спасибо! Мне удалось исправить ПОЧТИ ВСЁ! Я обновил вопрос своей новой информацией
Снова. Пожалуйста, отредактируйте свой вопрос, чтобы улучшить минимально воспроизводимый пример. В частности, расскажите, откуда взялся файл csv (т. е. как он создан; пожалуйста, дайте ссылку на файл csv, если можете…), а также как вы его читаете…
Ответы 1
Вот что ближе всего к решению (предоставлено JosefZ):
Вы столкнулись с двойным моджибаке (пример на Python): 'Fréchette|Fran̤ois'.encode( 'cp1252').decode( 'mac-romanian').encode( 'cp1252').decode( 'utf- 8') возвращает «Фрешетт|Франсуа».
Благодаря очень полезному ответу на этот вопрос мы установили, что это действительно случай Моджибаке.
Я добился прогресса в следующей конфигурации (python):
- Прочитать текущий CSV с не указанной кодировкой
- encode('cp1252').decode('mac-roman').encode('cp1252').decode('iso-8859-16')
- Запишите результат в новый CSV с указанной кодировкой «iso-8859-16».
В этой конфигурации многие символы теперь исправлены, но некоторые все еще отсутствуют. Я не знаю, означает ли это, что мне придется снова декодировать и кодировать (всего три раза), или я просто еще не нашел правильную конфигурацию для набора из двух декодируемых кодов.
Вот список символов, которые все еще повреждены после вышеуказанного перекодирования:
after re-encoding | just reading | desired outcome | notes
==============================================================================
� | Ì | Á | the lower case á works;
�_ | Ì_ | ü | the upper case Ü works
�_ | Ì_ | ä | I can't confirm whether upper case Ä works
| æ | I can't confirm whether this exists, but I confirmed one upper case that works; it's possible the file uses 'ae' instead
| œ | I can't confirm whether any of this exists; it's possible the file uses 'oe' instead
�_ | Ì_ | í | I can't confirm whether upper case Í works
�_ | Ì_ | ó | the upper case Ó works
�_ | Ì_ | þ | the upper case Þ doesn't exist, I think
Заключение:
Как видите, как чтение файла «как есть», так и чтение его после перекодирования, отображает все пропущенные символы как один и тот же битый символ, поэтому восстановить исходную информацию по ним кажется невозможным (информация заблудился в процессе Моджибаке). Боюсь, что эти строки придется исправлять вручную.
Можете ли вы предоставить четкий список символов, на которые они влияют сейчас и какими они должны быть в UTF-8 (с шестнадцатеричными кодами, чтобы избежать двусмысленности)? Я ожидаю, что с дюжиной или около того конкретных примеров кто-нибудь сможет обнаружить закономерность. Программная отмена может быть неоднозначной, если некоторые сопоставления много к одному.