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

Question

当涉及到Linux和Windows上字符的默认编码时，我认为这是一个常见的问题。然而，在我搜索完互联网之后，我没有任何简单的方法来自动修复它，因此我准备编写一个脚本来完成它。

下面是一个场景：

我在Windows系统上创建了一些文件，有些文件有非英语名称(在我的例子中是中文)。我用7-zip把它们压缩成一个压缩文件。之后，我将zip文件下载到Linux中，并提取Linux系统上的文件(Ubuntu16.04LTS)(默认存档程序)。正如我所猜到的，所有的非英语文件名现在都显示为一些损坏的字符！一开始我觉得用凸凹应该很容易，但是.

我试过了，上面写着：“跳过，已经是utf8了”。什么都没变。

然后，我决定使用Python编写一个工具来完成肮脏的工作，经过一些测试后，我到了不能将原始文件名与损坏的文件名相关联的地步(除非通过散列内容)。

下面是一个例子。我设置了一个webserver来列出Windows上的文件名，在python中用"gbk“编码后的一个文件显示为

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

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

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

用utf8解码它，就像u‘j\u255c\u2559.’。用gbk解码它会导致UnicodeDecodeError异常，我也尝试用utf8解码它，然后用gbk进行编码，但结果还是有些不同。

总之，在将原始文件名提取到linux系统后，我无法通过解码或编码来检查它的原始文件名。如果我真的想让一个程序来完成这项工作，我必须要么用一些编码选项重新处理归档文件，要么使用我的脚本，但是使用文件内容散列(如md5或sha1)在Windows上确定它的原始文件名。

除了比较两个系统之间的文件内容之外，在上述情况下，我还有没有机会从python脚本中推断出原始名称？

Answer 1

通过对普通编码的一些实验，我能够逆转您的莫吉贝克

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 -普通中文视窗编码

cp437 -常见的美国Windows控制台编码

utf8 -普通Linux编码