我背负着一堆文件，这些文件的名字乱七八糟，面目全非。尽管我或多或少知道这些名称最初包含什么，但手动修复它们会带来很多麻烦，所以我正在寻找一种自动执行此操作的方法。
这些汉字怎么可能变成这样：
### original => garbled
### UTF-8 UTF-8
### UCS-2 UCS-2
雨中 => ╙ъ╓╨
e9 9b a8 e4 b8 ad e2 95 99 d1 8a e2 95 93 e2 95 a8
96e8 4e2d 2559 044a 2553 2568
照片 => ╒╒╞м
e7 85 a7 e7 89 87 e2 95 92 e2 95 92 e2 95 9e d0 bc
7167 7247 2552 2552 255e 043c
女人 => ┼о╚╦
e5 a5 b3 e4 ba ba e2 94 bc d0 be e2 95 9a e2 95 a6
5973 4eba 253c 043e 255a 2566
童心 => ═п╨─
e7 ab a5 e5 bf 83 e2 95 90 d0 bf e2 95 a8 e2 94 80
7ae5 5fc3 2550 043f 2568 2500
绿肥红瘦 => ┬╠╖╩║ь╩▌
e7 bb bf e8 82 a5 e7 ba a2 e7 98 a6 e2 94 ac e2 95 a0 e2 95 96 e2 95 a9 e2 95 91 d1 8c e2 95 a9 e2 96 8c
7eff 80a5 7ea2 7626 252c 2560 2556 2569 2551 044c 2569 258c
我以前见过类似的事情发生，例如当一个 UTF-8 编码的序列被错误地解释为单字节（例如 Latin-1 或 CP1251）然后再次转换为 UTF-8 时，但这似乎并没有在这里就是这样。
实际上并不能保证原始编码是 UTF-8，它可能是 GB 或中国使用的其他一些遗留编码。
有任何想法吗？
╙ъ╓╨在 IBM 代码页 866中d3 ea d6 d0，它也在雨中GB2312、GBK 和 CP936 代码页中。所以这很可能是一个相当正常的代码页错误检测（GB2312 文本作为 IBM866）。此类错误的一个常见原因是跨文化压缩/解压缩，尽管我不能断言这发生在您的情况下。
您提供的示例似乎与第 3 行的使用 Un-ZIP 损坏的中文文件名一文中描述的示例有些相似 ：
文章 Zip 文件和编码 – 我讨厌你中显示了更多情况，其中给出了另一个示例，一个字符的三种不同编码，具体取决于该字符的压缩位置：
对于中文，使用较旧的编码方法可能有更多的编码。
如果您正在寻找一种自动方法来撤消乱码名称，那么在不知道原始编码以及所涉及的实用程序和操作系统的情况下，我什至不知道从哪里开始。
如果它们类似于上面的第 3 行，您可以从在 Linux 中压缩并在 Windows GB18030 中解压缩开始，或类似的尝试以反向执行这些压缩/解压缩操作。
您可以使用
convmv可以将文件名从一种字符集转换为另一种字符集的实用程序。类似的东西convmv -t cp866 -f gb2312 * ../target- 验证它做了什么，然后调用 with--notest。