我知道非標準的％uxxxx方案，但這似乎不是明智的選擇，因為該方案已被W3C拒絕。一些有趣的例子：心中的人物。如果我在瀏覽器中輸入：http://www.google.com/search?q=?然后復制并粘貼它，我看到這個URLhttp://www.google.com/search?q=%E2%99%A5這使得它看起來像Firefox（或Safari）正在這樣做。urllib.quote_plus(x.encode("latin-1"))'%E2%99%A5'這是有道理的，除了不能用Latin-1編碼的東西，比如三點字符?！绻逸斎險RLhttp://www.google.com/search?q=…進入我的瀏覽器然后復制粘貼，我明白了http://www.google.com/search?q=%E2%80%A6背部。這似乎是做的結(jié)果urllib.quote_plus(x.encode("utf-8"))這是有道理的，因為...不能用Latin-1編碼。但后來我不清楚瀏覽器是如何用UTF-8或Latin-1解碼的。因為這似乎含糊不清：In [67]: u"…".encode('utf-8').decode('latin-1')Out[67]: u'\xc3\xa2\xc2\x80\xc2\xa6'有效，所以我不知道瀏覽器是如何用UTF-8或Latin-1解碼的。使用我需要處理的特殊字符做什么是正確的？
3 回答
幕布斯6054654
TA貢獻1876條經(jīng)驗 獲得超7個贊
一般規(guī)則似乎是瀏覽器根據(jù)表單的內(nèi)容類型對表單響應(yīng)進行編碼。這是一個猜測，如果服務(wù)器發(fā)送給我們“text / xml; charset = iso-8859-1”，那么他們希望以相同的格式返回響應(yīng)。
如果您只是在URL欄中輸入一個URL，那么瀏覽器沒有可以使用的基頁，因此只需要猜測。所以在這種情況下它似乎一直在做utf-8（因為你的輸入都產(chǎn)生了三個八位字節(jié)的表格值）。
可悲的事實是，AFAIK沒有標準用于將查詢字符串中的值設(shè)置為什么字符，或者實際上URL中的任何字符都應(yīng)該被解釋為。至少在查詢字符串值的情況下，沒有理由認為他們一定不對應(yīng)的字符。
這是，你必須告訴你期望的字符集的查詢字符串編碼為---例如，在Tomcat中，你必須調(diào)用request.setEncoding（）（或類似的方法），你的服務(wù)器架構(gòu)的已知問題之前，你調(diào)用任何request.getParameter（）方法。關(guān)于這個主題的文檔缺乏可能反映了許多開發(fā)人員對該問題缺乏認識。（我經(jīng)常向Java受訪者詢問Reader和InputStream之間的區(qū)別是什么，并經(jīng)?？吹娇瞻椎臉幼樱?/p>
慕田峪4524236
TA貢獻1875條經(jīng)驗 獲得超5個贊
IRI（RFC 3987）是取代URI / URL（RFC 3986及更早版本）標準的最新標準。URI / URL本身不支持Unicode（嗯，RFC 3986增加了對未來基于URI / URL的協(xié)議的支持，但不會更新過去的RFC）?！埃XXXX”方案是在某些情況下允許Unicode的非標準擴展，但并非每個人都普遍實現(xiàn)。另一方面，IRI完全支持Unicode，并要求在進行百分比編碼之前將文本編碼為UTF-8。
添加回答
舉報
0/150
提交
取消