Mac OS X中文件系统的Unicode编码在Python中不正确？

Question

在OS X和Python中与Unicode文件名有点冲突。我试图在后面的代码中将文件名用作正则表达式的输入，但文件名中使用的编码似乎与sys.getFileSystemCoding（）告诉我的不同。获取以下代码：

#!/usr/bin/env python
# coding=utf-8

import sys,os
print sys.getfilesystemencoding()

p = u'/temp/s/'
s = u'åäö'
print 's', [ord(c) for c in s], s
s2 = s.encode(sys.getfilesystemencoding())
print 's2', [ord(c) for c in s2], s2
os.mkdir(p+s)
for d in os.listdir(p):
  print 'dir', [ord(c) for c in d], d

输出如下：

utf-8
s [229, 228, 246] åäö
s2 [195, 165, 195, 164, 195, 182] åäö
dir [97, 778, 97, 776, 111, 776] åäö

所以，文件系统编码是utf-8，但是当我用它来编码我的文件名时，它将不同于用相同的字符串创建一个dir名称。我希望当我使用字符串åäääääää创建一个dir，并读回它的名称时，它应该使用与直接应用编码相同的代码。

如果我们看一下代码点97、778、97、776、111、776，基本上都是添加了变音符号的ASCII字符，例如o+¨=o，这使得它是两个字符，而不是一个字符。如何避免这种差异，Python中是否有一个编码方案与OS X的这种行为相匹配，为什么getFileSystemCoding（）没有给出正确的结果？

还是我搞砸了？

Answer 1

getfilesystemencoding()给出了正确的响应（编码），但它没有告诉您unicode normalisation form。

特别是，HFS+文件系统使用UTF-8编码和接近“D”的规范化形式（这要求将ö等组合字符分解为o¨）。HFS+还与Unicode版本3.2中存在的规范化表单绑定，如苹果公司的documentation for the HFS+ format中所详述的。

Python的^{}方法在表单之间进行转换，如果在调用前加上ucd_3_2_0对象，则可以将其约束到Unicode版本3.2：

filename = unicodedata.ucd_3_2_0.normalize('NFC', unicode(filename, 'utf-8')).encode('utf-8')

Answer 2

MacOS X使用一种特殊的分解UTF-8来存储文件名。如果需要读取文件名并将其写入“普通”UTF-8文件，则必须将其规范化：

filename = unicodedata.normalize('NFC', unicode(filename, 'utf-8')).encode('utf-8')

从这里开始：https://web.archive.org/web/20120423075412/http://boodebr.org/main/python/all-about-python-and-unicode