我手头上有一堆文件，名字乱得让人无法辨认。虽然我或多或少知道这些名字原本包含什么，但手动修复它们会很麻烦，所以我正在寻找一种自动修复的方法。
到底发生了什么，让这些汉字变成了这样：
### 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 或中国使用的其他传统编码。
有任何想法吗？
答案1
╙ъ╓╨位于d3 ea d6 d0IBM 代码页 866 中，而该代码页也位于雨中GB2312、GBK 和 CP936 代码页中。因此，这很可能是相当正常的代码页错误检测（将 GB2312 文本误认为 IBM866）。
echo e2 95 99 d1 8a e2 95 93 e2 95 a8 | unhex | iconv -t cp866 | iconv -f gb2312
答案2
造成这种错误的一个常见原因是跨文化的 zip/unzip，尽管我不能断言在您的情况下发生了这种情况。
您给出的例子看起来与文章中描述的例子有些相似 解压ZIP后中文文件名损坏 第 3 行：
文章中还展示了更多案例 Zip 文件和编码 – 我讨厌你其中给出了另一个示例，其中针对一个字符给出了三种不同的编码，具体取决于该字符的压缩位置：
| 文件名 | Windows 中的 Zip | Linux 中的 Zip | Mac OS 中的 Zip |
|---|---|---|---|
| ñ | a4（扩展的 US-ASCII/CP437） | C3 B1 (UTF-8 NFC) | 6E CC 83 (UTF-8 NFD) |
对于中文，使用较旧的编码方法可以实现更多的编码。
如果您正在寻找一种自动方法来撤消乱码的名称，那么在不知道原始编码和所涉及的实用程序和操作系统的情况下，我甚至不知道从哪里开始。
如果它们与上面的第 3 行类似，您可以先在 Linux 中压缩，然后在 Windows GB18030 中解压缩，或者尝试类似方法以反向执行这些压缩/解压缩操作。
答案3
您可以使用convmv实用程序将文件名从一种字符集转换为另一种字符集。例如convmv -t cp866 -f gb2312 * ../target- 验证其功能，然后使用 调用--notest。