保管箱 Unicode 编码冲突答案

【问题标题】：dropbox Unicode Encoding Conflict保管箱 Unicode 编码冲突
【发布时间】：2014-01-07 11:04:37
【问题描述】：

我有一个 python 脚本，它查询数据库的客户和订单信息，使用 jinja2 根据该数据创建一个乳胶模板，最后调用

subprocess.call(['/usr/texbin/pdflatex', filename], shell = False)

文件名是乳胶模板。

相应文件名的文件夹以客户命名。我在德国经营，所以有些文件名包含“元音变音”，例如 ö。

我有一个这样的文件夹结构：

.
└── invoices
    ├── customer_no_umlaut
            ├── invoice_no_umlaut_01
            └── invoice_no_umlaut_02
    └── cüstömer_with_ümläüt
            ├── invoice_with_ümlaut_01
            └── invoice_with_ümlaut_02

这一切都在我的本地计算机上运行良好。

但是，由于我需要共享这些文件，我希望将 pdf 文件放在 Dropbox 文件夹中。

所以在我的代码中，我插入了 Dropbox 文件夹的路径，而不是原始的本地文件夹。

然后我得到的是我的 Dropbox 文件夹中的乳胶模板，文件名后面的括号中包含此文本：

Unicode Encoding Conflict

如

"Rechnung_Gedöns_4-724_(Unicode-Codierungskonflikt).tex"

看来 Dropbox 对我的 unicode 字符集不满意。

我觉得奇怪的是，这仅适用于文件名。 python 脚本能够在 Dropbox 中使用从数据库中检索到的具有相同编码的客户名称创建文件夹。

有人对如何解决这个问题有任何想法吗？

【问题讨论】：

标签： python-2.7 unicode latex dropbox jinja2

【解决方案1】：

我或多或少地设法解决了这个问题。

无奈之下，我删除了 Dropbox 中包含变音符号的客户文件夹。然后，我再次重新运行了问题中描述的脚本。脚本根据各自的客户数据创建目标文件夹的路径。如果该文件夹不存在，则正在创建它。

由于我删除了文件夹，它们现在被重新创建。然后将乳胶模板放在里面并用

调用

subprocess.call(['/usr/texbin/pdflatex', filename], shell = False)

一切正常。

我想旧版本的文件夹一定是发生 unicode 冲突的地方。

【讨论】：