我有一個網站在路徑部分中處理「/」和「％2F」查詢字符串）的URL不同。根據RFC或現實世界，這是一件壞事嗎？我使用我正在使用的Web框架（Ruby on Rails）以及下面的層（Passenger，Apache，例如，我必須爲Apache啓用「ALLOW_ENCODED_SLASHES」）時遇到一些小驚喜， 。我現在傾向於完全擺脫編碼的斜槓，但是我不知道是否應該提交錯誤報告，我發現涉及編碼斜線的奇怪行爲。是在HTTP URL的路徑部分中等效於編碼斜槓（「％2F」）的斜槓（「/」）
至於爲什麼我在首位編碼的斜線，基本上我有途徑，如這樣的：
:controller/:foo/:bar
其中：foo是類似的東西可以包含斜線的路徑。我認爲要做的最簡單的事情就是URL跳轉foo，這樣路由機制就忽略了斜槓。現在我懷疑了，很明顯，框架並不真的支持這個，但根據RFC，這樣做是錯誤的嗎？
下面是一些信息，我已經收集：
RFC 1738（網址）：
通常一個URL時，有一個字節由字符表示的相同的解釋，當它編碼。但是，對於保留字符，這不是真的：編碼爲特定方案保留的字符可能會改變URL的語義。
RFC 2396（URI）來：
這些字符被稱爲 「保留」，因爲URI組件內它們的使用被限制在他們的保留的目的。如果URI組件的數據與保留目的衝突，那麼衝突數據必須在形成URI之前轉義。
（在這裏所做的逃逸意味着其他的東西比編碼保留字？）
RFC 2616（HTTP/1.1）：
比在 「保留」 之外字符和「不安全「（參見RFC 2396 [42]）等同於它們的」「％」HEX HEX「編碼。
還有this bug report爲Rails，他們似乎期望編碼的斜線表現不同：
對，我期望不同的結果，因爲他們在不同的資源指向。
它正在尋找根目錄中的文字文件'foo/bar'。非轉義版本正在尋找目錄foo中的文件欄。
從RFC中可以清楚的看出，raw與encoded是相當於未經保留的字符，但保留字符的故事是什麼？
相關：http://stackoverflow.com/q/14631200/1591669 – unor 2013-02-07 00:47:08
PHP使用前端控制器的用戶：$ _GET＆$ _REQUEST已經被urldecoded了。這可能會導致斜線問題，因爲您無法分辨斜線是什麼，以及％2F是什麼。如果您確實需要查看發送的請求，請查看$ _SERVER ['REQUEST_URI']。另請參見[urldecode（）@ php.net]（http://php.net/manual/en/function.urldecode.php） – 2014-11-12 18:33:03