为什么在 iconv 二进制文件上使用 libiconv 时会得到不同的结果？答案

【问题标题】：Why do I get different results when using libiconv over iconv binary?为什么在 iconv 二进制文件上使用 libiconv 时会得到不同的结果？
【发布时间】：2015-08-04 13:32:13
【问题描述】：

这是我使用 UCS-2 编码的示例字符串：

abvgdđežzijklmnjoprstćuvhcčdžš1234567890*+;'

当使用 iconv 二进制文件将 UCS-2 转换为 iso ISO-8859-1//TRANSLIT 时，我得到：

abvgd?ezzijklmnjoprstcuvhccdzs1234567890*+;'

现在我想在 go 项目中使用 libiconv。我正在使用这个库 github.com/qiniu/iconv 作为 libiconv 的绑定。但是当使用绑定时，我得到：

abvgd?e?zijklmnjoprst?uvhc?d??1234567890*+;'

就像在 go 中使用库时应用不同的音译规则一样。

我检查了 go 绑定库，一切似乎都井井有条；只传递字节，因此不会发生“信息丢失”。

在使用 libiconv 时我还有什么需要注意的吗？是否有一些环境上下文可以触发不同的音译行为？

EDIT（关于调用的附加解释）：

我有两个文件“ucs-2.txt”和“latin1.txt”。 ucs-2.txt 文件包含 UCS-2 编码的字符串，latin1.txt 包含运行得到的字符串：

iconv -f UCS2 -t ISO-8859-1//TRANSLIT --verbose data/encoding/ucs-2.txt > data/encoding/latin1.txt

在 go 中，我使用这些行从这些文件中提取内容：

var err error
ucs2, err = ioutil.ReadFile("data/encoding/ucs-2.txt")
if err != nil {
    log.Fatal(err)
}
latin1, err = ioutil.ReadFile("data/encoding/latin1.txt")
if err != nil {
    log.Fatal(err)
}

这个函数正在做转换：

func convertEnc(content []byte) ([]byte, error) {
    cd, err := iconv.Open("ISO-8859-1//TRANSLIT", "UCS2")
    if err != nil {
        return nil, err
    }
    defer cd.Close()
    var outbuf [255]byte
    res, _, err := cd.Conv(content, outbuf[:])
    log.Printf("result: %+q", res)
    return res, err
}

我正在使用 DeepEqual 进行测试：

reflect.DeepEqual(res, latin1)

【问题讨论】：

"//TRANSLIT" 是一个 GNU 扩展。也许 Go 绑定正在使用另一个非 gnu 库？

标签： c go iconv libiconv

【解决方案1】：

第一个输出包括音译，即某些字符（例如ž）被音译成它们不太正确的“普通”对应物（z），以便在不支持原始的编码中表示字符（此处为 ž，拉丁语 1）。

第二个输出没有音译任何内容，它删除了任何无法在目标编码中表示的字符（ž、ć、... in Latin-1）。

因此，我怀疑您可以使用与库不同的选项来生成二进制文件。对libiconv不熟悉，貌似//TRANSLIT部分被省略了或者你使用的功能不支持...？

【讨论】：

谢谢我了解音译的工作原理。 “//TRANSLIT”是触发音译的参数。没有它，第一个未知字符将结束转换。因此，我假设使用库会触发一些音译，但映射与二进制不同。
@AleksandarJanković：输入字符串中的那些字符不能用 Latin-1 表示。第一次运行确实将它们音译成“普通”字符，第二次没有。所以你调用了不同的功能。到底有什么区别很难说，因为您没有在问题中显示实际的调用。（提示，提示。）

【解决方案2】：

音译取决于语言环境。可能是您的 libiconv 缺少/有错误的语言环境。或者您使用的语言环境没有配置音译。

请查看this bug report，因为它有一些示例和关于此主题的讨论。

【讨论】：