浏览器字符集的优先顺序答案

【问题标题】：Browser charsets order of precedence浏览器字符集的优先顺序
【发布时间】：2012-01-12 19:38:57
【问题描述】：

客户端浏览器正在发送标头HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.3。我只提供带有正确标题的 utf8 网页，但浏览器正在发布来自使用 ISO-8859-1 字符集编码的表单的数据。我的问题是，浏览器是否总是更喜欢按其 ACCEPT_CHARSET 标头顺序排列的字符集，以便我可以可靠地编写一个中间件，该中间件将使用第一个条目（在本例中为 ISO-8859-1）解码任何已发布的数据，并将其编码为 utf8。

更新：

我用accept-charset="utf-8" 更新了表单标签，但我仍然看到出现非Unicode 字符。用户从其他地方（lastpass、excel 文件）复制/粘贴密码是否可能会注入非 unicode 字符？

【问题讨论】：

标签： python html character-encoding

【解决方案1】：

请求标头Accept-Charset（可能映射到服务器端HTTP_ACCEPT_CHARSET）表达了客户端的偏好，当服务器能够以不同的编码提供资源时使用。服务器可能会忽略它，而且通常会。

如果您的页面是 UTF-8 编码并声明为 UTF-8，那么您页面上的任何表单都将以 UTF-8 编码发送其数据，除非您指定 accept-charset 属性。因此，如果浏览器以 ISO-8859-1 编码发布数据，那么这就是浏览器错误。但是，这需要在得出结论之前进行分析。

有一种包含一些特殊字符的 ald 技术，为安全起见，使用字符引用编写，作为隐藏字段的值。然后，服务器端处理程序可以获取该字段的值并检测编码不匹配，甚至可以从特殊字符的编码形式中试探性地推断出实际编码。

【讨论】：

所以我猜浏览器有一个错误。它绝对不会将数据发布为 UTF8。我已经添加了接受字符集，如果我只是使用浏览器的 HTTP_ACCEPT_CHARSET 作为指针以防出现错误，我会得到一致的结果。
如果这发生在多个浏览器中，可能会有不同的解释。您是否拥有或可以构建一个展示问题的公共页面 URL？我无法重建它。浏览器倾向于发送像您提到的那样的 Accept-Charset 标头，即使页面本身和表单数据传输是 UTF-8 也是如此。标题取决于它们的配置，而不是页面。我怀疑可能有一些软件组件（服务器端）在数据到达您的代码之前执行代码转换。
我在 Mac 上运行，这个问题似乎与 Windows 用户输入的字符特别相关，这些字符随后被编码为扩展的 ascii 字符集，比如带有尖锐重音的“E”被编码为 \xC9，当它出现错误时然后在服务器上被盲目地视为 unicode。
这是否处理通过<input type=file> 包含的文件中的数据？这可以解释很多......浏览器通常按原样发送文件内容并且不指示字符编码。如果你有一个 UTF-8 编码的表单并且它被用来提交一个 windows-1252 编码的纯文本文件，那么它的内容就是这样发送的，声明为 text/plain（无字符集），即使是普通字段的内容是 UTF-8 编码的。坏消息是浏览器通常无法告诉编码，因此它既不能声明它也不能对数据进行代码转换，
它没有。任何地方都没有文件上传。

【解决方案2】：

我不确定所有浏览器是否总是喜欢以相同特定顺序排列的字符集，但您可以在表单中设置接受字符集，这会强制浏览器发送 utf-8 编码数据。

像这样：

<form accept-charset="utf-8"></form>

【讨论】：

这应该可以，但我已经进行了 4 天的更改，但我仍然收到错误。