URL中的分號作爲查詢字符串的分隔符

Question

我一直聽說W3C建議使用「;」而不是「&」作爲查詢字符串分隔符。

我們推薦HTTP服務器實現者，特別是CGI 實現者支持使用「;」代替「&」以保存作者 以這種方式轉義「&」字符的麻煩。

有人請解釋爲什麼「;」被推薦而不是「&」？

此外，我嘗試使用";"而不是"&"。 （例如：.com?str1=val1;str2=val2）。在閱讀Request.QueryString["str1"]時，我收到「val1;str2=val2」。所以如果推薦使用";"，我們該如何讀取查詢字符串？

Answer 1

由於鏈接的文檔說，;建議在&因爲

使用「&」字符分隔表單域，其在SGML屬性值使用分隔字符實體引用進行交互。

例如，假設你希望你的網址是...?q1=v1&q2=v2

有什麼錯&有。但是，如果要將該查詢放入HTML屬性<a href="...?q1=v1&q2=v2">中，則其中斷，因爲在HTML屬性中，&代表字符實體的開始。你必須跳過&作爲&，給<a href="...?q1=v1&amp;q2=v2">，如果你不需要，它會更容易。

;不會像這樣超載;你可以把一個放在HTML屬性中，而不用擔心。因此，如果服務器將;識別爲查詢參數分隔符，則會更簡單。

但是，從外觀上看（根據您的實驗），ASP.Net 並不是認識到這一點。如何獲得它？我不確定你可以。

Answer 2

總之，HTML是一個很大的混亂（由於它的寬大），並使用分號有助於簡化這是一個很大。

爲了使用分號作爲分隔符，我不知道.NET是否允許這種自定義，或者我們的開發人員是否需要編寫自己的方法來處理QueryString。 .NET確實讓我們可以訪問原始的QueryString，我們可以從那裏運行它。這就是我所做的。我編寫了我自己的方法，但這並不難，但是它花費了大量的測試時間和調試，其中一些是微軟在處理代理對時甚至不符合Web標準的錯誤。我確信我的實現可以使用包括多語言平面在內的全部Unicode字符（因此適用於中文和日文字符等）。在我添加我自己的發現之前，我還需要確認幷包括Rawling，Jeevan和BeniBela在羅琳的回答中指出的以及他們對這樣的答案的評論的偉大信息：HTML中的錯誤不能逃避它們，但是它通常起作用，但僅僅是因爲解析器如此寬容。因此，我也解釋了爲什麼這會導致錯誤的編碼（這可能是大多數開發人員的犧牲品）。

人們不能依賴於查詢字符串這個寬大不當編碼與符號的，而有時這種寬大導致討厭的錯誤。比方說，例如一個QueryString傳遞一個隨機的ASCII字符串（或用戶輸入），它們沒有正確編碼。然後'amp''後面'&'被解碼，意想不到的後果是'amp''實質上是「吞噬」。 （通過吞嚥，我的意思是它被'吃掉'或者它不見了。）一個實際的使用場景是當用戶被要求輸入數據庫並且用戶輸入HTML（像StackOverflow這樣的）時，但是因爲它不是張貼正確然後討厭的錯誤發展。

的真正的優勢「;」分隔符很簡單：正確編碼和號分隔的QueryStrings對HTML頁面（也是XML）中的URL字符串採取兩個步驟的複雜操作。將第一個鍵和值分解爲URL編碼，然後將其全部連接起來，然後整個QueryString或URL將被編碼爲HTML（或者對於使用與HTML編碼類似的編碼進行編碼的XML）。另外請不要忘記，HTML編碼和URL編碼的編碼過程是不同的，重要的是它們是不同的。開發者在兩者之間需要小心。由於它們是相似的，新手程序員混淆它們並不罕見。

潛在問題的URL的一個很好的例子是在查詢字符串傳遞兩個名稱/值時：

• 一個= '我&你'，並
• B = '你&我'。

這裏，使用 '&' 作爲分隔符，然後 '？A =我+％26 +你& B =你+％26 +我' 是一個適當的查詢字符串，但它shud也被HTML被寫入之前編碼HTML源代碼。這對於無bug是很重要的。大多數開發人員不小心執行第一個URL的這個兩步過程對鍵和值進行編碼，然後對HTML源代碼中的完整URL進行HTML編碼。難怪爲什麼，當我不得不坐下來認真思考這個過程並徹底檢驗我的結論時。當名稱值爲'year =año'時進行成像，或者當我們需要使用代理對代表它們的中文或日文字符時，成像更復雜！

對於a和b，使用時與上述相同的密鑰值對「;」作爲分隔符，這個過程要簡單得多。事實上，和號分隔符使得這個過程比使用分號分隔符複雜兩倍多！以下是使用';'表示的相同信息作爲分隔符：'？a =我+％26 +你; b =你+％26 +我'。我們注意到唯一的區別是字符串中沒有'&'。但是用這個';'分隔符意味着不需要第二個HTML編碼URL或QueryString的進程。現在想象一下，如果我正在編寫HTML並想要正確的HTML，並且需要編寫HTML來解釋所有這些內容！所有這些'&'的HTML編碼確實增加了很多複雜性（對許多開發人員來說，也有很多混亂）。

新手開發商WUD根本就不是HTML編碼查詢字符串或URL，這是正確的，當;是分隔符。但是，當＆符號編碼不正確時，會留下錯誤空間。所以'someText = blah & amp; blah'wud 需要正確的編碼。

同樣在.NET中，我們可以爲我們的方法編寫XML文檔。那麼，就在今天，我寫了一個使用上面的'a = me +％26 + you & b = you +％26 + me'的例子。在我的XML中，我不得不手動輸入所有那些功能; XML的字符實體。在XML文檔中，它很挑剔，所以必須正確編碼＆符號。但HTML中的寬容性增加了含糊性。

也許這不是太混亂。但所有的困惑或困難都是由於使用了一種被HTML編碼作爲分隔符的字符，因此'&'是罪魁禍首。分號可以緩解所有這些併發症。

最後一個考慮：'&'分隔符使得這個過程變得複雜多了，所以我不奇怪爲什麼QueryStrings中的代理對的Microsoft實現仍然不遵循官方規範。如果您編寫自己的方法，則必須說明Microsoft錯誤地使用百分比編碼替代對。官方規範禁止UTF-8中代理對的百分比編碼。因此，任何編寫自己的方法的人也可以處理全部的Unicode字符，請注意這一點。