Ostatnio badałem ciągi zapytań HTTP, zastanawiając się nad możliwościami interfejsu dostępu do usługi sieciowejAPI. I wydaje się bardzo niedokładny.

w rzeczywistościRFC 3986 (Uniform Resource Identifier (URI): ogólna składnia) nie mówi nic o formacie fragmentu ciągu zapytania i kończy się określeniem, które znaki są dozwolone i jak kodować inne znaki. (Wrócę do tego później.)

Jedyne, co znalazłem, to specyfikacja HTML na temat zniekształcania formularzy w ciągu zapytania (HTML 4.01; 17.13.4 Typy treści formularza, aplikacja / x-www-form-urlencoded). Algorytm HTML 5 wydaje się wystarczająco blisko (4.10.22.5 Dane formularza zakodowane w adresie URL).

To może wydawać się OK. W końcu dlaczego ktoś chciałby ustawić format ciągu zapytania dla wszystkich innych. Po co? Ale czy są jakieś inne (niż HTML) dobrze ustalone standardy? Czy ktoś inny używa innego formatu?

Pytanie boczne dotyczy tutaj [] w nazwach pól formularza. PHP używa tego, aby zapewnić, że wszystkie wystąpienia pola są obecne$_GET zmienna superglobalna. (W przeciwnym razie występuje tylko ostatnie wystąpienie.)

Ale odRFC 3986 wydaje się, że żaden z nich[ ani] są dozwolone w ciągu zapytania. Jednak moje eksperymenty z różnymi przeglądarkami sugerowały, że żadna przeglądarka nie koduje tych znaków, a one znajdują się w URI w taki sposób ...

Czy to prawdziwa praktyka? Czy testuję go niepoprawnie? Przetestowałem z PHP 5.3.17 na IIS 7. Używając Internet Explorer, Firefox i Chrome. Potem porównałem to, co jest$_SERVER['QUERY_STRING'] i$_GET.

Kolejnym pytaniem jest wsparcie dla separacji średników w prawdziwym życiu.

Specyfikacja HTML 4.01 (B.2.2 Zmienia wartości atrybutów URI) zaleca serwerom HTTP akceptowanie średnika (;) jako separator parametrów (w przeciwieństwie do znaku ampersand&).

Czy obsługuje go jakikolwiek serwer? Czy ktoś tego używa? Czy warto się tym przejmować (rozważając dozwolone formaty ciągu zapytania dla usługi internetowej)?

W jaki sposób można obsługiwać znaki inne niż ASCII?

Specyfikacja HTML 4.01 (B.2.1 Znaki inne niż ASCII w wartościach atrybutów URI) jasno określa, co URI opisujący RFC stwierdził w pierwszej kolejności: znaki spoza ASCII nie są dozwolone w URI. Jednak specyfikacja uwzględnia istniejącą praktykę (używania nielegalnych URI) i porady dotyczące zmiany takich znaków na kodowanie UTF-8, a następnie traktowania każdego bajtu za pomocą standardowego kodowania szesnastkowego URI.

Z moich testów wynika, że ​​na przykład Chrome i Firefox tak robią. Ale Internet Explorer nie wysłał takich postaci, jak one. PHP częściowo z tym poradził.$_SERVER['QUERY_STRING'] i$_GET zawierały te postacie. Ale$_SERVER['REQUEST_URI'] zawarte? zamiast.

Czy są jakieś standardy lub praktyki, jak podejść do takich przypadków?

Kolejne powiązane pytanie brzmi: w jaki sposób autorzy powinni publikować (przez URI) zasoby o nazwach zawierających znaki inne niż ASCII (na przykład krajowe)? Biorąc pod uwagę wszystkie różne strony (kod HTML, żądanie wysyłania przeglądarki, zapisywanie pliku przez przeglądarkę, dysk, odbieranie i przetwarzanie żądania serwera oraz przechowywanie pliku) wydaje się, że jest to niemożliwe, aby działał spójnie. A przynajmniej nigdy mi się nie udało.

Jeśli chodzi o strony internetowe, jestem już do tego przyzwyczajony i zawsze zastępuję znaki narodowe odpowiednimi łacińskimi znakami bazowymi. Ale jeśli chodzi o pliki zewnętrzne (pliki PDF, obrazy…), to „czuje się źle”, aby „obniżyć” nazwy. Zwłaszcza, jeśli oczekuje się, że użytkownicy będą zapisywać te pliki na dysku. Jak sobie z tym poradzić?