2009-11-19 16 views
3

我最近遇到了一個特定於Firefox編碼URL直接輸入地址欄的編碼問題。它基本上看起來像URL的默認Firefox字符編碼不是UTF-8,大多數瀏覽器都是這樣。此外,看起來他們正在嘗試根據URL的內容根據使用什麼字符編碼做出明智的決定。您認爲Google如何處理此編碼問題?

例如,如果您直接輸入網址到地址欄(我使用的是Firefox 3.5.5)以「Q」參數,你會得到如下結果:

對於給定的查詢字符串參數,這是它實際上是如何在http請求中編碼的:
1)... q =Književni - > q = Knji%9Eevni(這看起來是iso-8859-1編碼的)
2)... q =漢字 - > q =%E6%BC%A2%E5%AD%97(這看起來是UTF-8編碼的)
3)... q =Književni漢字 - > Knji%C5%BEevni% E6%BC%A2%E5%AD%97(這似乎是UTF-8編碼......這很奇怪,因爲注意到該值的第一部分與1相同,即iso-885 9-1編碼)。

所以,這真的不應該是一個大問題,對吧?那麼,對我來說,並不完全,但有點。在我正在處理的應用程序中,我們的全局導航中有一個搜索框。當用戶在我們的搜索框中提交一個搜索詞時,'q'參數(就像我們的例子中那樣,包含查詢字符串值的參數)在請求中被提交,並且是UTF-8編碼的,一切都很好。

但是,出現在地址欄中的URL包含該URL的解碼形式,因此q參數看起來像「q =Književni」。現在,正如我之前提到的,如果用戶然後按下ENTER鍵提交地址欄中的內容,則「q =Književni」參數現在編碼爲iso-8859-1,並以「q = Knji%9Eevni」。這個問題是我們總是期待一個UTF-8編碼的URL ......所以當我們收到這個參數時,我們的應用程序不知道如何解釋它,它可能會導致一些奇怪的結果。

正如我前面提到的,這似乎只是一個Firefox問題,用戶實際上會遇到這種情況很少見,所以它對我們來說並不太重要。不過,我恰巧注意到Google實際上很好地處理了這個問題。打字使用任何的查詢字符串參數的不同編碼形式以下網址將在谷歌返回不錯的結果:

http://www.google.com/search?q=Knji%C5%BEevni
http://www.google.com/search?q=Knji%9Eevni

所以我的真正的問題是,你怎麼看待他們處理這種情況?另外,還有其他人看到相同的奇怪的Firefox行爲?

回答

2

看起來像使用拉丁-1,除非任何字符不能用該編碼表示,否則使用UTF-8。

如果確實如此,在另一端解決此問題的方法是假定您收到的所有內容都是UTF-8,並將其驗證爲UTF-8。如果UTF-8驗證失敗,則認爲它是latin-1(iso-8859-1)。

由於UTF-8的構造方式,實際上並非UTF-8的東西在驗證爲UTF-8時很可能不會通過。

儘管如此,這種可能性還是存在的,我認爲Firefox的行爲不是一個好主意,儘管毫無疑問他們已經將它作爲一種妥協 - 就像與服務器的兼容性一樣,如果他們加入的話不會知道UTF-8它。

+0

是的,這是奇怪的行爲。 IE瀏覽器(8)和Chrome似乎總是編碼我使用上述UTF-8相同的URL ...所以我猜測也許UTF-8編碼實際上是它們的默認編碼。 但是,是的,我希望有一個更容易的修復,但它看起來可能不是這種情況。現在最難的部分是確切地說明如何驗證UTF-8編碼(使用Java):/感謝您的幫助! – JasonStoltz 2009-11-20 13:51:12

+0

看起來Bugzilla中實際存在一些代表此問題的報告錯誤。 https://bugzilla.mozilla.org/show_bug.cgi?id=461304,https://bugzilla.mozilla.org/show_bug.cgi?id=451359 – JasonStoltz 2009-11-20 14:16:17

+0

我不知道很多關於Java,但根據維基百科, InputStreamReader和OutputStreamWriter類支持原生UTF-8。你告訴它在構造函數中解釋爲UTF-8,然後假設你得到一個異常,你就可以捕獲它(並嘗試另一種編碼)。 – thomasrutter 2009-11-21 06:52:59

0

有URL中的幾個部分。域名根據IDN(國際域名)規則編碼(http://en.wikipedia.org/wiki/Internationalized_domain_name)。

,你關心的部分來(通常)從一種形式。源頁面的編碼決定了編碼(在%轉義之前)。 html中的表單元素也可以採用覆蓋頁面設置的編碼屬性。

所以它不是火狐的故障時,引用頁/表單的編碼是決定性因素。這是標準的行爲。

+1

問題是,當我將它作爲表單提交時,它以UTF-8編碼,這正在發生。我的問題是,當響應返回並呈現頁面時,查詢字符串參數實際上會以地址欄中的未編碼狀態出現......「q =Književni」。當我然後明確地按下輸入的URL地址欄上的回車,它看起來沒有將該URL與當前頁面相關聯(因此該頁面的源編碼),所以它看起來像它試圖使用iso -8859-1編碼。 – JasonStoltz 2009-11-20 13:43:46