В текстовых редакторах файлы Python UTF-8, созданные на Python, показаны как бред

Question

это мой первый вопрос здесь, и если его формат не соответствует ожидаемому, извините заранее.

У меня есть небольшая утилита, которая читает текстовые файлы ISO-8859-9 и выдает ее UTF-8копии.Метод, который я нашел, заключается в использовании методов кодирования и декодирования, когда я реализую путь старших, текстовые редакторы показывают символы юникода как нерелевантные символы.

Проблема в том, что файлы записаны правильно.Для проверки я создал вручную созданную версию этого файла в TextEdit на Mac.Шестнадцатеричный дамп конвертированной версии и md5sum одинаковы для созданного вручную.Тем не менее, и Textedit, и Kwrite (или Kate) в KDE показывают абсурдные символы, даже если я выберу UTF-8 в качестве входной кодировки.Почему это происходит и как я могу это решить?

Большое спасибо.

Обновление:

od -c выводится ниже:

Прежде всего, файл ISO-8859-9:

0000000  374 360   i 376 347 366 334 320 335 336 307 326   T   e   s   t
0000020    T   e   s   t                                                
0000024

PythonСоздано UTF-8:

0000000    ü  **   ğ  **   i   ş  **   ç  **   ö  **   Ü  **   Ğ  **   İ
0000020   **   Ş  **   Ç  **   Ö  **   T   e   s   t   T   e   s   t    
0000037

Ручное создание UTF-8:

0000000    ü  **   ğ  **   i   ş  **   ç  **   ö  **   Ü  **   Ğ  **   İ
0000020   **   Ş  **   Ç  **   Ö  **   T   e   s   t   T   e   s   t    
0000037

Фактический код:

def convert_file(path_of_text_file):
    try:
        original_file = open(path_of_text_file, 'rb')
        file_contents = unicode(original_file.read(), 'iso-8859-9')
        original_file.close()

        new_file = open("untitled2.txt", 'w+b')
        new_file.write(file_contents.encode('utf8'))
        new_file.close()
    except IOError:
        pass

Также да, файл ручной работы открывается простохорошо.Также он имеет тот же вывод md5sum и hex, что и генерируемый питоном.

od -xc выводит:

Снова исходный файл ISO-8859-9:

0000000      f0fc    fe69    f6e7    d0dc    dedd    d6c7    6554    7473
         374 360   i 376 347 366 334 320 335 336 307 326   T   e   s   t
0000020      6554    7473                                                
           T   e   s   t                                                
0000024

Файл UTF-8, сгенерированный Python:

0000000      bcc3    9fc4    c569    c39f    c3a7    c3b6    c49c    c49e
           ü  **   ğ  **   i   ş  **   ç  **   ö  **   Ü  **   Ğ  **   İ
0000020      c5b0    c39e    c387    5496    7365    5474    7365    0074
          **   Ş  **   Ç  **   Ö  **   T   e   s   t   T   e   s   t    
0000037

Файл UTF-8, созданный вручную:

0000000      bcc3    9fc4    c569    c39f    c3a7    c3b6    c49c    c49e
           ü  **   ğ  **   i   ş  **   ç  **   ö  **   Ü  **   Ğ  **   İ
0000020      c5b0    c39e    c387    5496    7365    5474    7365    0074
          **   Ş  **   Ç  **   Ö  **   T   e   s   t   T   e   s   t    
0000037

Еще одно интересное замечание: BBEdit прекрасно обрабатывает созданные на Python файлы.

Answer 1

Я решил проблему.Это смешанная проблема вилок ресурсов OSX, TextEdit и небольшого количества PEBKAC.Вот как я решил это:

Я скопировал файлы на мой (fat32) флеш-диск, поэтому я получаю вилки ресурсов как ".filename".Я заметил, что файл, который я написал с помощью python, не содержит веток ресурсов.Интересно, что когда я открыл файл с флэш-диска с помощью TextEdit с принудительной кодировкой UTF-8, все работало нормально (странно, что это не работало, когда я пытался скопировать файлы на флэш-память).

С этим свидетельством я могускажем, что TextEdit хранит кодировку файла в своей ветке ресурсов, не угадывая ее каждый раз, в отличие от команды file.Что еще интереснее, теперь мой Linux boxen ведет себя хорошо, я не могу сказать, почему.

В результате код работает так, как должен, и все в порядке.Неудачный текстовый редактор, а не Python.

Спасибо всем,

Счастливого взлома.

Answer 2

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

Используйте команду file, чтобы узнать, как OS / X определяет тип файла.

Answer 3

Я быстро реализовал то, что, как я полагаю, делает ваш скрипт преобразования Python:

iso = "\374\360i\376\347\366\334\320\335\336\307\326Test Test"
tmp = iso.decode('iso-8859-9')
utf = tmp.encode('utf-8')
out = open('utf.txt', 'wb')
out.write(utf)

Выход od -xc:

0000000    bcc3    9fc4    c569    c39f    c3a7    c3b6    c49c    c49e
        303 274 304 237   i 305 237 303 247 303 266 303 234 304 236 304
0000020    c5b0    c39e    c387    5496    7365    2074    6554    7473
        260 305 236 303 207 303 226   T   e   s   t       T   e   s   t
0000040

Скриншоты из Textedit в Mac: