文本编辑器将python创建的UTF-8文件显示为乱码

Question

这是我在这里的第一个问题，如果它的格式不符合预期，请提前抱歉。

我有一个小实用程序，它读取ISO-8859-9文本文件并生成其UTF-8副本。我找到的方法是使用编码和解码方法，当我实现长老的方式时，文本编辑器将unicode字符显示为无关字符。

问题的转折是文件写得正确。为了便于检查，我在Mac的TextEdit中创建了同一文件的手工创建版本。转换后的版本的十六进制转储和md5sum对于手工创建的版本是相同的。然而，即使我选择UTF-8作为输入编码，KDE上的Textedit和Kwrite（或Kate）也显示出荒谬的字符。为什么会这样，我该如何解决？

非常感谢。

更新

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 Created UTF-8：

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

Hand Created 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和python生成的十六进制输出。

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

Python生成的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

手工制作的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编写的文件没有资源分支。有趣的是，当我使用带有强制UTF-8编码的TextEdit从闪存盘打开文件时，一切正常（奇怪的是，当我在将文件复制到闪存之前尝试时它不起作用）。

有了这个证据，我可以说TextEdit正在将文件的编码存储在其资源分支中，而不是每次都像文件命令那样猜测它。更有趣的是，现在我的Linux boxen似乎表现得很好，我不能说为什么。

因此，代码可以正常工作，一切都很好。 dud是TextEdit，而不是python。

谢谢大家，

快乐的黑客攻击。

Answer 2

我快速实现了我认为你的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

Mac中Textedit的截图：

Answer 3

由于文件内容相同，因此必须存在确定文件解释方式的文件内容之外的内容。文件名是显而易见的嫌疑人。如果您在不同的目录中以相同的方式命名文件，它们的行为是否相同？

使用file命令查看OS / X如何猜测文件类型。