你正在使用的Go版本是什么(go version
)?
$ go version
go version go1.11 linux/amd64
这个问题在最新的版本中是否会重现?
是的
你正在使用什么操作系统和处理器架构(go env
)?
amd64, linux
你做了什么?
- 调用charset.Lookup("us-ascii")来获取编码
https://godoc.org/golang.org/x/net/html/charset#Lookup
e, _ := charset.Lookup("us-ascii") - 调用encoding.NewDecoder().String(string([]byte{0x80}))并获取结果
res, _ := e.NewDecoder().String(string([]byte{0x80})) - 打印结果
你期望看到什么?
我期望看到一个字符,因为值超出了US-ASCII的范围(最高有效位为1)
你看到了什么?
我将看到来自Windows 1252编码的字符€。这是因为go在US-ASCII中重复使用了Windows 1252。对于其他字符集中的越界字符也会出现类似的问题,例如tis-620Map到windows874。现在如果我想要正确解析文本,我需要遍历解码后的runes并测试它们是否有越界的。如果我想只为tis-620字符使用windows874,我就需要进行类似的手动排除越界字符的操作。我不知道如何创建自己的字符集,以避免这些问题。
3条答案
按热度按时间txu3uszq1#
这似乎遵循了 https://www.w3.org/TR/encoding/#names-and-labels ,其中
us-ascii
是windows 1252
的别名。qmelpv7a2#
有趣的是,US-ASCII和Windows1252是不同的字符集(Windows 1252是一个超集)。
参见:https://zh.wikipedia.org/wiki/ASCII#字符集
以及:https://zh.wikipedia.org/wiki/Windows-1252#字符集
其他语言,如Java允许用户区分这些字符集。对于解码遗留文本,使用像windows1252这样的超集字符集并不是理想的选择,因为如果用户的文本无效,那么无法在子集中表示的无效字符可能会被插入到结果中。这要求开发者实现一些解决方法,以确保结果中不包含无效文本。
67up9zun3#
/cc @rsc