客户端浏览器发送标题HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.3。我只以utf8的方式为网页提供正确的标题，但浏览器发布来自使用ISO-8859-1字符集编码的表单的数据。我的问题是，浏览器总是会按照其ACCEPT_CHARSET标题的顺序选择字符集，因此我可以可靠地编写一个中间件，它将使用第一个条目（本例中为ISO-8859-1）解码任何发布的数据，并将其编码为utf8。浏览器字符集优先顺序
UPDATE：
我的表单标签与accept-charset="utf-8"更新，我仍然看到非Unicode字符出现。是否有可能用户从其他地方（lastpass，excel文件）复制/粘贴密码可能会注入非Unicode字符？
当服务器能够服务于不同的编码的资源所使用的请求报头Accept-Charset（其可以被映射到HTTP_ACCEPT_CHARSET服务器端），表示客户端的偏好。服务器可能会忽略它，并且经常会这样。
如果您的页面采用UTF-8编码并声明为这样，那么除非您指定accept-charset属性，否则页面上的任何表单都将以UTF-8编码方式发送其数据。因此，如果浏览器发布数据为ISO-8859-1编码，那么这是一个浏览器错误。但是，这需要在得出结论之前进行分析。
还有一种将包含一些特殊字符（使用安全字符引用编写）作为隐藏字段的值的技术。然后，服务器端处理程序可以获取此字段的值并检测编码不匹配，甚至可以从特殊字符的编码形式中启发式推导出实际编码。
我不确定是否所有的浏览器总是以特定的顺序喜欢charset，但是你可以在表单中设置accept-charset，这会强制浏览器发送utf-8编码的数据。
像这样：
<form accept-charset="utf-8"></form>
这应该工作，但我已经有了这个改变现场生活了4天，我仍然得到错误。 – Endophage 2012-01-17 18:50:11
所以我猜浏览器有一个错误。绝对不会将数据发布为UTF8。我添加了accept-charset，如果我只是在出现错误的情况下使用浏览器的HTTP_ACCEPT_CHARSET作为指针，我会得到一致的结果。 – Endophage 2012-01-13 01:08:48
如果在几个浏览器中发生这种情况，可能会有不同的解释。你有没有或者可以构建一个公共页面URL来证明问题？我无法重建它。即使页面本身和表单数据传输为UTF-8，浏览器也倾向于发送类似于您所提到的Accept-Charset标头。标题取决于它们的配置，而不是页面上。我怀疑可能有一些软件组件（服务器端）在数据到达您的代码之前执行代码转换。 – 2012-01-13 07:56:15
我在Mac上运行，这个问题似乎与Windows用户输入的字符相关，后来用扩展的ascii字符集编码，如“E”，其中一个尖锐的重音被编码为\ xC9，当它被盲目地当作unicode服务器。 – Endophage 2012-01-13 20:23:18