2015-03-24 43 views
0

我在我的某個網站上遇到了與Cookie相關的編碼問題。如何用ASCII表示急性口音?

用戶輸入查詢時Usuário,其中有重音的,而這被放在一個cookie。針對Cookie響應的原始HEX是(對於Usuário字符串):

55 73 75 C3 A1 72 69 6F 

當我看到它在瀏覽器中,它看起來像這樣:

enter image description here

...這是真的亂。我需要解決這個問題。

然後我去這個網站:http://www.rapidtables.com/convert/number/hex-to-ascii.htm和轉換的十六進制值,看看它會是什麼樣子。而我得到了相同的輸出:

enter image description here

權。這意味着HEX代碼是錯誤的。然後我試圖將Usuário轉換爲ASCII以查看它應該如何。我用這個網站:http://www.asciitohex.com/,這是結果:

enter image description here

對於我驚訝的是,HEX正是被顯示出來凌亂之一。爲什麼???

,如何表示ASCII Usuário這樣我就可以把它放在一個cookie?我應該手動編碼嗎? PS:我使用ASP.NET,以防萬一它很重要。

+0

ASCII不支持重音字符。您可以嘗試一些本地字符集(如cp850),但最好將所有環境設置爲UTF8,並強制客戶端的瀏覽器爲UTF8以及正確的元標記和標題 – SztupY 2015-03-24 23:46:26

+0

請注意,您發佈的十六進制表示形式爲utf8而不是ascii。 – SztupY 2015-03-24 23:47:19

+0

謝謝@SztupY,但你怎麼知道它是UTF-8? – 2015-03-24 23:50:50

回答

1

截至2015年,存儲字符數據的網頁標準是UTF-8,而不是ASCII。 ASCII實際上只包含代碼頁的前128個字符,並且不包含任何種類的重音字符。要將重音字符添加到這128個字符中,有許多遺留解決方案:代碼頁。他們每個都將128個不同的字符添加到默認的ASCII列表,從而允許表示256個不同的字符

問題在於,這並沒有很好地解決問題:基於ASCII的代碼頁彼此或多或少是互不相容的(除了前128個字符),並且通常無法通過編程方式知道哪個代碼頁是在使用中。

解決的辦法之一是UTF-8,這是編碼unocde字符集的方式(包含大部分在世界各地使用的字符,等等),同時試圖保持與ASCII兼容。前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(視圖,數據庫等)。