Busted encoding in XLSX document - что такое кодирование?

Question

Мне был предоставлен документ XLSX, над которым работал другой пользователь, и от случайного осмотра он выглядит так, что кодировка полностью разрушена. Я использовал Excel 2011 для открытия файла XLSX и сохранил документ в виде файла CSV для Windows, чтобы я мог запустить скрипт через него и выяснить, какая кодировка была. Однако, делая это, я только немного смутился.

Диапазон ASCII в 0-127 все кажется правильным и читаемым. Затем я написал скрипт для анализа всего файла CSV и только для вывода ячеек с байтами 80 по ff. Глядя на различные клетки и заполняя пробелы, я считаю, я нашел следующие переводы - все они не могут быть 100% точным:

• e5 ca =>пустой
• cc 5f => ä, как в Bättner
• cc a4 => с, как в Жан-Франсуа
• cc a6 => а, как и в Hölzlestr
• cc a8 => I, как в Жан-Бенуа
• cc a9 => е, как в Дюпре
• cc ac => е, как и в Hélène
• cc b1 => N, как в Муньоса
• cc c1 => а, как и в Мулла и Чавез
• cc d9 => ß, как и в Auerstraße
• cc e4 => Э, как в
Эмиль

Кроме того, приставка cc c4 e5 появляется несколько раз в данных и, по-видимому, сопоставляется с тем же, что и cc - например, cc c4 e5 c1 появляется для отображения того же символа (á), что и cc c1.

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

EDIT Итак, одно из решений получило правильное решение о том, что многие из этих полей выглядели как UTF-8, интерпретируемые как Windows-1252, закодированные как MacRoman. Мне удалось перевернуть MacRoman на Windows-1252 и получить действительные байтовые последовательности UTF-8. Однако это не распространяется на все случаи ... он не объясняет последовательность cc c4 e5, и одно из кодировок в таблице выше, которое я предположил, было вне базы - cc 5f не обращается в ä при обратном. Тем не менее, я обнаружил, что на самом деле существует несколько кодировок, таких как cc 5f, которые, я думаю, могут иметь ключ или два. Вот два байтовых строк, что моя предыдущая стратегия не может декодировать ...

4a 65 74 74 cc c4 e5 f8 cc e2 e5 c0 cc e2 e5 5f

48 cc 5f e5 5f e5 5f cc 5f e5 a6 e5 a8 65 72

Это 5f придумывает очень много ...

Answer 1

Многие из тех, кто похож на Mac, возможно, были вовлечены в какой-то момент, и путь был чем-то вроде utf-8 -> cp125 (2/4) -> mac_roman.

>>> for char in chars[1:]: 
    print(char, hexlify(char.encode("utf-8").decode("cp1252").encode("mac_roman"))) 
...  
ç b'cca4' 
ö b'cca6' 
î b'cca8' 
é b'cca9' 
è b'ccac' 
ñ b'ccb1' 
á b'ccc1' 
ß b'ccd9' 
É b'cce4' 

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