Question

我认为这是Linux和Windows上字符的默认编码时的常见问题。然而，在我搜索互联网后，我没有任何简单的方法来自动修复它，因此我即将编写一个脚本来执行此操作。

以下是该方案：

我在Windows系统上创建了一些文件，其中一些文件是非英文名称（特别是我的中文）。我用7-zip将它们压缩成zip文件。之后我将zip文件下载到Linux并解压缩Linux系统上的文件（Ubuntu 16.04 LTS）（默认存档程序）。正如我猜测的那样，所有非英文文件名现在都显示为一些损坏的字符！起初我觉得用convmv应该很容易，但是......

我尝试了convmv，它说：“跳过，已经是utf8”。什么都没有改变。

然后我决定编写一个使用Python来完成脏工作的工具，经过一些测试后，我无法将原始文件名与损坏的文件名关联起来（除非通过对内容进行散列。）< / p>

这是一个例子。我设置了一个Web服务器来列出Windows上的文件名，一个文件在python中用“gbk”编码后显示为

u'j\u63a5\u53e3\u6587\u6863'

我可以查询Linux系统上的文件名。我可以使用如上所示的名称直接创建文件，名称为CORRECT。我也可以将unicode gbk字符串编码为utf8编码并创建一个文件，名称也是CORRECT。（因此我不能同时做它们，因为它们确实是同一个名字）。现在，当我读取之前提取的文件名时，应该是同一个文件。但文件名完全不同：

'j\xe2\x95\x9c\xe2\x95\x99.....'

使用utf8对其进行解码，它就像是你的'u uc5c \ u2559 ......'。用gbk解码导致UnicodeDecodeError异常，我也试图用utf8解码它然后用gbk编码，但结果还是别的。

总结一下，在将原始文件名解压缩或编码后，我无法检查原始文件名。如果我真的想让一个程序完成这项工作，我可能要么可能会使用一些编码选项重新进行存档，或者只是使用我的脚本但使用文件内容哈希（如md5或sha1）来确定其原始文件Windows上的名称。

除了比较两个系统之间的文件内容之外，我是否还有机会从python脚本中推断原始名称？

Answer 1

通过对常见编码的一些实验，我能够扭转你的mojibake：

bad = 'j\xe2\x95\x9c\xe2\x95\x99\xe2\x94\x90\xe2\x94\x8c\xe2\x95\xac\xe2\x94\x80\xe2\x95\xa1\xe2\x95\xa1'
>>> good = bad.decode('utf8').encode('cp437').decode('gbk')
>>> good
u'j\u63a5\u53e3\u6587\u6863'        # u'j接口文档'

gbk - 常见的中文Windows编码
cp437 - 常见的美国Windows OEM控制台编码
utf8 - 常见的Linux编码

Windows文件名在Linux中显示已损坏的字符

1 个答案: