我的某个网站上存在与Cookie相关的编码问题。
用户正在输入Usuário
,其具有强烈的重音,并且正在放入Cookie中。 cookie响应的原始HEX是(对于Usuário
字符串):
55 73 75 C3 A1 72 69 6F
当我在浏览器中看到它时,它看起来像这样:
......这真是一团糟。我需要解决这个问题。
然后我去了这个网站:http://www.rapidtables.com/convert/number/hex-to-ascii.htm并转换了HEX值以查看它的外观。我得到了相同的输出:
右。这意味着HEX代码错误。然后我尝试将Usuário
转换为ASCII以查看它应该如何。我使用了这个网站:http://www.asciitohex.com/,这就是结果:
令我惊讶的是, HEX恰好是出现凌乱的。为什么???
如何在ASCII中表示Usuário
,以便将其放入cookie中?我应该手动编码吗?
PS:我正在使用ASP.NET,以防万一。
答案 0 :(得分:1)
截至2015年,存储字符数据的Web标准为UTF-8而非ASCII。 ASCII实际上只包含代码页的前128个字符,并且不包含任何类型的重音字符。要为这128个字符添加重音字符,有许多传统解决方案:代码页。它们每个都为默认的ASCII列表添加了128个不同的字符,从而允许代表256个不同的字符。
问题是,这并没有妥善解决问题:基于ASCII的代码页彼此或多或少不兼容(前128个字符除外),并且通常无法以编程方式知道哪个代码页被使用了。
其中一个解决方案是UTF-8,它是一种在尝试保持与ASCII兼容的同时对unocde字符集(包含世界上使用的大多数字符等)进行编码的方法。在这两种情况下,前128个字符实际上是相同的,但之后UTF-8字符变为多字节:一个字符使用一系列字节进行编码(通常为2-3,取决于需要编码的字符)
问题是如果你使用某种基于ASCII的单字节代码库(如ISO-8859-1),它以单字节编码支持的字符,但你的输入实际上是UTF-8,它将编码重音字符多个字节(您可以在HEX示例中看到这一点。á
编码为C3 A1
:两个字节)。如果您尝试在基于ASCII的代码页中读取这两个字节,该代码页对每个字符使用单个字节(在西欧,此代码页通常为ISO-8859-1),则这两个字节中的每一个都将以两个不同的字符进行重新呈现
在网络世界中,默认编码为UTF-8,因此您的客户通常会使用UTF-8发送请求。 ASP.NET具有Unicode感知能力,因此可以处理这些请求。然而,在你的代码中,有些代码将UTF-8转换为ISO-8859-1,然后再转换为UTF-8。这可能发生在各个层上。当你遇到问题时,它可能发生在cookie层,这有时会产生问题(here is how it worked in 2009)。如果你想正确支持重音字符,你还应该仔细检查你的应用程序是否在其他地方使用UTF-8(视图,数据库等)。