修复编码问题

Question

我使用 cURL 抓取了一些评论以进行一个小实验。除了一些有编码问题的文件之外，这几乎可以正常工作。

特别是，没有问题：

• 没有任何特殊字符的文件
• 具有外来字符集（中文、日文、韩文等）的文件

但是，这些确实有问题：

• 只有几个特殊字符的文件

例如，意大利语文本：

mi sono fatto dare un menù classico per vedere i loro piatti che solitamente offrono e penso proprio di tornarci

在这种特殊情况下，ù 应该是 ù。 “文件”实用程序告诉我该文件确实是一个 UTF-8 文件：“HTML 文档，UTF-8 Unicode 文本，行很长”。但是 vim 和其他编辑器显示的字符不正确。

我想了解问题的根本原因。 cURL 是否猜错了原始 HTML 的编码并将单个字符保存为两个 UTF8 字符？有什么办法可以强制 cURL 做正确的事吗？

是否有在一堆文件中自动检测此问题的方法？我不想重新下载所有文件。

是否有自动解决此问题的方法？即，将 ù 替换为 ù （和其他类似问题）并另存为 UTF8？我最接近的是使用 iconv：

iconv -f UTF-8 -t ISO-8859-1//TRANSLIT file

这解决了问题，但将文件保存为 ISO-8859-1（这不是我想要的）。我也不确定这是否会解决每个编码错误的问题。

上述句子的十六进制转储：

0000000 696d 7320 6e6f 206f 6166 7474 206f 6164
0000010 6572 7520 206e 656d c36e c283 20b9 6c63
0000020 7361 6973 6f63 7020 7265 7620 6465 7265
0000030 2065 2069 6f6c 6f72 7020 6169 7474 2069
0000040 6863 2065 6f73 696c 6174 656d 746e 2065
0000050 666f 7266 6e6f 206f 2065 6570 736e 206f
0000060 7270 706f 6972 206f 6964 7420 726f 616e
0000070 6372 0a69                              
0000074

上面inconv命令后同一句话​​的Hexdump：

0000000 696d 7320 6e6f 206f 6166 7474 206f 6164
0000010 6572 7520 206e 656d c36e 20b9 6c63 7361
0000020 6973 6f63 7020 7265 7620 6465 7265 2065
0000030 2069 6f6c 6f72 7020 6169 7474 2069 6863
0000040 2065 6f73 696c 6174 656d 746e 2065 666f
0000050 7266 6e6f 206f 2065 6570 736e 206f 7270
0000060 706f 6972 206f 6964 7420 726f 616e 6372
0000070 0a69                                   
0000072

Answer 1

我怀疑您遇到了一些相互复杂的小问题：

1. 您的终端仿真设置为“Windows-1252”或“ISO-8859-1”。它应该设置为“UTF-8”。
2. 您已将输出复制并粘贴到另一个文件中以执行十六进制转储。这会复制屏幕上呈现的文本。十六进制转储似乎包含可能来自剪贴板的其他控制字符。
3. 您的十六进制转储处于大端模式，这使得肉眼难以看到单词或解码 UTF-8。

当我获取“http://www.tripadvisor.it/ShowUserReviews-g187849-d2263221-r233247966-Sant_Eustorgio-Milan_Lombardy.html”时，我的终端设置为“UTF-8”，我的语言环境设置为“en_GB.UTF-8”（您应该将其设置为适合您的任何区域，但请确保它以“.UTF-8”结尾），文件正确保存为 UTF-8 并显示在 vim、cat 和 less。

Answer 2

我认为set fileencoding=utf-8 对您来说是错误的选择，因为它设置了写入文件的编码。显示的编码是用set encoding=utf-8 设置的，所以你应该试试这个。