客戶端瀏覽器發送標題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