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

Question

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

我有一个小型实用程序，可以读取 ISO-8859-9 文本文件并生成其 UTF-8 副本。我找到的方法是使用encode和decode方法，当我实现前辈的方式时，文本编辑器将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 创建了 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

也可以，手工制作的文件可以正常打开。它还具有与 python 生成的相同的 md5sum 和十六进制输出。

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 似乎表现良好，我说不出为什么。

因此，代码可以正常工作并且一切正常。没用的是 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 是如何猜测文件类型的。