我不确定其中哪一个是您的问题,因为有多种方法可以解决此问题,因此我将介绍所有可能性:
首先,确保文件实际保存为 UTF-8。默认情况下,记事本和许多其他编辑器将以您的系统编码保存文件,这可能类似于 cp1252。测试“看起来正确”和“当脚本将这些字符写入文件并且我在记事本中打开该文件时,它看起来正确”并不能告诉您任何信息;显然,如果您保存一个 cp1252 文件并将其作为 cp1252 打开,它看起来是正确的。
只需在顶部添加“coding=utf-8”并不会神奇地改变文件的保存方式(除了一些智能编辑器,如 emacs)。它只是告诉 Python“这个源文件是 UTF-8”,即使它真的是别的东西。因此,Python 最终将您的 cp1252 解释为 UTF-8 并获得 mojibake,就像用 a-with-circumflex 代替画线字符一样。
您通常最好使用显式反斜杠转义,例如\u250c
代替┌─
,特别是如果您甚至不知道如何判断文件是否为 UTF-8,更不用说如何修复它了。
其次,您几乎不想将非 ASCII 字符放入str
文字中;unicode
除非您有充分的理由不这样做,否则请使用文字。
最重要的是,如果您传递draw.text
一个str
,PIL 将使用您的默认字符集对其进行解码——这可能又不是 UTF-8。因此,即使到目前为止所有其他内容都是正确的,您的代码也会移交一些 UTF-8 以解析为 cp1252,所以再次mojibake。使用unicode
文字可以完全避免这个问题;否则,您需要通过text.decode('utf-8')
.
把所有这些放在一起:
text = u"\u250c\u2500\u2510\u2502\u2514\u2518\u255e\u2550\u2561\u2564\u2567\u2558\u255b"
现在编码声明和用于保存文件的实际编码无关紧要,因为文件是纯 ASCII。
但是您可能仍然会得到缺少字符的矩形,因为许多字体没有画线字符。我不知道你cour.ttf
的字体是什么,但我在我的系统上发现了两种 Courier TTF 字体,一种来自旧的 Mac OS,一种来自 Windows XP,但都没有。如果这是您的问题,您显然需要使用不同的字体。
另一种可能性:如果您仍然使用上述修复程序获得 mojibake,则cour.ttf
可能不是 Unicode 排序的字体文件,而是较旧的 TTF 顺序之一。字体查看器应该会显示文件的 TTF 顺序。(我很确定 Windows 自带一个,但我不知道它在 Windows 7 中的位置或如何使用它。)然后你需要在加载字体时传递正确'unic'
的东西来代替。encoding
但是大多数不是unic
或者symb
可能没有画线字符的字体。