Tło (pytanie poniżej)
Szukałem tego w Google w tę iz powrotem, czytając RFC i pytania SO próbując to złamać, ale nadal nie mam gniazda.
Więc myślę, że po prostu głosujemy na „najlepszą” odpowiedź i to wszystko, prawda?
Zasadniczo sprowadza się to do tego.
3.4. Składnik zapytania
Składnik zapytania to ciąg informacji, które mają być zinterpretowane przez zasób.
query = *uricW składniku zapytania znaki „;”, „/”, „?”, „:”, „@”, „&”, „=”, „+”, „,” I „$” są zarezerwowane.
Pierwszą rzeczą, która mnie zaskakuje, jest to, że * uric jest zdefiniowany w ten sposób
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
Jest to jednak nieco wyjaśnione w akapitach, takich jak
„Zarezerwowana” klasa składni powyżej odnosi się do tych znaków, które są dozwolone w obrębie URI, ale które mogą być niedozwolone w określonym składniku ogólnej składni URI; służą jako ograniczniki elementów opisanych w sekcji 3.
Znaki w zestawie „zarezerwowanym” nie są zarezerwowane we wszystkich kontekstach. Zestaw znaków faktycznie zarezerwowanych w ramach dowolnego składnika URI jest definiowany przez ten składnik. Ogólnie znak jest zarezerwowany, jeśli semantyka identyfikatora URI ulegnie zmianie, jeśli znak zostanie zastąpiony jego kodowaniem ze znakami ucieczki US-ASCII.
Ten ostatni fragment wydaje się nieco cofnięty, ale wyraźnie stwierdza, że zarezerwowany zestaw znaków zależy od kontekstu. Jednak 3.4 stwierdza, że wszystkie zastrzeżone znaki są zarezerwowane w komponencie zapytania, jednak jedyną rzeczą, która zmieniłaby tutaj semantykę, jest unikanie znaku zapytania (?), Ponieważ URI nie definiują pojęcia ciągu zapytania.
W tym momencie całkowicie zrezygnowałem z RFC, ale uznałem RFC 1738 za szczególnie interesujący.
Adres URL HTTP ma postać:
http://<host>:<port>/<path>?<searchpart>W składnikach <path> i <searchpart>, „/”, „;”, „?” są zastrzeżone. Znak „/” może być użyty w HTTP do określenia struktury hierarchicznej.
Interpretuję to przynajmniej w odniesieniu do adresów URL HTTP, które RFC 1738 zastępuje RFC 2396. Ponieważ zapytanie URI nie ma pojęcia ciągu zapytania, również interpretacja zarezerwowanego tak naprawdę nie pozwala mi definiować ciągów zapytań, tak jak jestem przyzwyczajony już robię.
Pytanie
Wszystko zaczęło się, gdy chciałem przekazać listę numerów wraz z prośbą o inny zasób. Nie myślałem o tym zbyt wiele i po prostu przekazałem to jako wartości oddzielone przecinkami. Ku mojemu zdziwieniu udało się jednak uniknąć przecinka. page.html?q=1,2,3Zakodowane zapytanie page.html?q=1%2C2%2C3działa, ale jest brzydkie i nie spodziewałem się tego. Wtedy zacząłem przeglądać RFC.
Moje pierwsze pytanie brzmi po prostu, czy kodowanie przecinków jest naprawdę konieczne?
Moja odpowiedź, zgodnie z RFC 2396: tak, zgodnie z RFC 1738: nie
Później znalazłem powiązane posty dotyczące przekazywania list między wnioskami. Gdzie podejście CSV było gotowe jako złe. Pojawiło się to zamiast tego (nie widziałem tego wcześniej).
page.html?q=1;q=2;q=3
Moje drugie pytanie, czy to prawidłowy adres URL?
Moja odpowiedź, zgodnie z RFC 2396: nie, zgodnie z RFC 1738: nie (; jest zastrzeżone)
Nie mam żadnych problemów z przekazywaniem csv, o ile jest to liczba, ale tak, istnieje ryzyko konieczności kodowania i dekodowania wartości w tę iz powrotem, jeśli przecinek nagle jest potrzebny do czegoś innego. W każdym razie wypróbowałem ciąg zapytania ze średnikiem dwukropka w ASP.NET i wynik nie był tym, czego się spodziewałem.
Default.aspx?a=1;a=2&b=1&a=3
Request.QueryString["a"] = "1;a=2,3"
Request.QueryString["b"] = "1"
Nie widzę, jak bardzo różni się to od podejścia csv, ponieważ kiedy pytam o „a”, otrzymuję ciąg znaków z przecinkami. ASP.NET z pewnością nie jest implementacją referencyjną, ale jeszcze mnie nie zawiódł.
Ale co najważniejsze - moje trzecie pytanie - gdzie jest specyfikacja tego? i co byś zrobił lub czego nie zrobiłeś?