kodowanie adresów URL

Kodowanie adresów URL , oficjalnie znane jako kodowanie procentowe , to metoda kodowania dowolnych danych w identyfikatorze URI (Uniform Resource Identifier ) ​​przy użyciu tylko ograniczonej liczby znaków US-ASCII , które są dozwolone w identyfikatorze URI. Chociaż jest to znane jako kodowanie adresów URL , jest również używane bardziej ogólnie w głównym zestawie Uniform Resource Identifier (URI), który obejmuje zarówno Uniform Resource Locator (URL), jak i Uniform Resource Name (URN). Jako taki jest również używany do przygotowywania danych o application/x-www-form-urlencoded media type , który jest często używany do przesyłania danych formularza HTML w żądaniach HTTP .

Kodowanie procentowe w identyfikatorze URI

Rodzaje znaków URI

Znaki dozwolone w identyfikatorze URI są zastrzeżone lub niezarezerwowane (lub znak procentowy jako część kodowania procentowego). Znaki zastrzeżone to znaki, które czasami mają specjalne znaczenie. Na przykład ukośniki są używane do oddzielania różnych części adresu URL (lub bardziej ogólnie identyfikatora URI). Niezarezerwowane znaki nie mają takiego znaczenia. Używając kodowania procentowego, zarezerwowane znaki są reprezentowane za pomocą specjalnych sekwencji znaków. Zestawy znaków zastrzeżonych i niezarezerwowanych oraz okoliczności, w których niektóre znaki zastrzeżone mają specjalne znaczenie, zmieniały się nieznacznie z każdą wersją specyfikacji regulujących identyfikatory URI i schematy URI.

RFC 3986 sekcja 2.2 Znaki zastrzeżone (styczeń 2005)
! # $ & ' ( ) * + , / : ; = ? @ [ ]
RFC 3986 sekcja 2.3 Niezarezerwowane znaki (styczeń 2005)
A B C D mi F G H I J k Ł M N O P Q R S T u V W X Y Z
A B C D mi F G H I J k l M N o P Q R S T u w w X y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

Inne znaki w identyfikatorze URI muszą być zakodowane procentowo.

Zarezerwowane znaki

Gdy znak ze zbioru zastrzeżonego („zarezerwowany znak”) ma specjalne znaczenie („zastrzeżony cel”) w określonym kontekście, a schemat URI mówi, że konieczne jest użycie tego znaku w jakimś innym celu , wówczas znak musi być zakodowany procentowo . Kodowanie procentowe znaku zastrzeżonego obejmuje konwersję znaku na odpowiadającą mu wartość bajtową w ASCII , a następnie przedstawienie tej wartości jako pary cyfr szesnastkowych (jeśli jest pojedyncza cyfra szesnastkowa, dodawane jest wiodące zero ). Cyfry poprzedzone a znak procentu ( % ) jako znak ucieczki , są następnie używane w identyfikatorze URI zamiast znaku zastrzeżonego. (W przypadku znaku innego niż ASCII jest on zwykle konwertowany na sekwencję bajtów w UTF-8 , a następnie każda wartość bajtu jest reprezentowana jak powyżej).

Zarezerwowany znak / , na przykład, jeśli jest używany w komponencie „ścieżka” identyfikatora URI , ma specjalne znaczenie jako ogranicznik między segmentami ścieżki. Jeśli zgodnie z danym schematem URI / musi znajdować się w segmencie ścieżki, to w segmencie należy użyć trzech znaków %2F lub %2f zamiast surowego / .

Zarezerwowane znaki po kodowaniu procentowym
␣ ! " # $ % & ' ( ) * + , / : ; = ? @ [ ]
%20 %21 %22 %23 %24 %25 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5D

Zarezerwowane znaki, które nie mają zastrzeżonego celu w określonym kontekście, mogą być również zakodowane procentowo, ale nie różnią się semantycznie od tych, które nie są.

w elemencie „ zapytania ” identyfikatora URI (część po znaku ? ), znak / nadal jest uważany za znak zastrzeżony, ale zwykle nie ma on zarezerwowanego celu, chyba że określony schemat identyfikatora URI stanowi inaczej. Znak nie musi być zakodowany procentowo, jeśli nie ma zastrzeżonego celu.

Identyfikatory URI, które różnią się tylko tym, czy znak zastrzeżony jest zakodowany procentowo, czy występuje dosłownie, są zwykle uważane za nierównoważne (oznaczające ten sam zasób), chyba że można ustalić, że dane zastrzeżone znaki nie mają zastrzeżonego celu. To określenie zależy od reguł ustanowionych dla znaków zastrzeżonych przez poszczególne schematy URI.

Niezarezerwowane znaki

Znaki z zestawu niezarezerwowanego nigdy nie muszą być kodowane procentowo.

Identyfikatory URI, które różnią się tylko tym, czy niezarezerwowany znak jest zakodowany procentowo, czy występuje dosłownie, są z definicji równoważne, ale w praktyce procesory URI mogą nie zawsze rozpoznawać tę równoważność. Na przykład konsumenci URI nie powinni traktować %41 inaczej niż A lub %7E inaczej niż ~ , ale niektórzy tak robią. Aby zapewnić maksymalną interoperacyjność, producenci identyfikatorów URI są zniechęceni do kodowania procentowego niezarezerwowanych znaków.

Znak procentowy

Ponieważ znak procentu ( % ) służy jako wskaźnik oktetów zakodowanych procentowo, musi być zakodowany procentowo jako %25 , aby ten oktet mógł być używany jako dane w identyfikatorze URI.

Dane arbitralne

Większość schematów URI obejmuje reprezentację dowolnych danych, takich jak adres IP lub ścieżka systemu plików , jako składników URI. Specyfikacje schematów URI powinny, ale często tego nie robią, zapewniać jawne mapowanie między znakami URI a wszystkimi możliwymi wartościami danych reprezentowanymi przez te znaki.

Dane binarne

Od czasu opublikowania RFC 1738 w 1994 roku określono, że schematy zapewniające reprezentację danych binarnych w URI muszą dzielić dane na 8-bitowe bajty i kodować procentowo każdy bajt w taki sam sposób jak powyżej. Na przykład wartość bajtu 0x0F powinna być reprezentowana przez %0F , ale wartość bajtu 0x41 może być reprezentowana przez A lub %41 . Zwykle preferowane jest używanie niezakodowanych znaków dla znaków alfanumerycznych i innych znaków niezarezerwowanych, ponieważ skutkuje to krótszymi adresami URL.

Dane postaci

Procedura kodowania procentowego danych binarnych była często ekstrapolowana, czasami niewłaściwie lub bez pełnego określenia, w celu zastosowania do danych opartych na znakach. W sieci WWW lata formacyjne, kiedy zajmował się znakami danych w repertuarze ASCII i używał odpowiadających im bajtów w ASCII jako podstawy do określania sekwencji zakodowanych procentowo, praktyka ta była stosunkowo nieszkodliwa; po prostu założono, że znaki i bajty są odwzorowywane jeden do jednego i są wymienne. Potrzeba reprezentowania znaków spoza zakresu ASCII szybko jednak rosła, a schematy i protokoły URI często nie zapewniały standardowych zasad przygotowywania danych znakowych do włączenia do URI. W konsekwencji aplikacje internetowe zaczęły używać różnych wielobajtowych, stanowych i inne kodowania niezgodne z ASCII jako podstawa kodowania procentowego, co prowadzi do niejasności i trudności w wiarygodnej interpretacji identyfikatorów URI.

Na przykład wiele schematów i protokołów URI opartych na dokumentach RFC 1738 i 2396 zakłada, że ​​znaki danych zostaną przekonwertowane na bajty zgodnie z pewnym nieokreślonym kodowaniem znaków , zanim zostaną przedstawione w URI przez niezarezerwowane znaki lub bajty zakodowane procentowo. Jeśli schemat nie pozwala identyfikatorowi URI na podanie wskazówki, jakie kodowanie zostało użyte, lub jeśli kodowanie koliduje z użyciem ASCII do kodowania procentowego znaków zarezerwowanych i niezarezerwowanych, identyfikator URI nie może być wiarygodnie zinterpretowany. Niektóre schematy w ogóle nie uwzględniają kodowania i zamiast tego sugerują, że znaki danych są odwzorowywane bezpośrednio na znaki URI, co pozostawia implementacjom decyzję, czy i jak kodować procentowo znaki danych, które nie należą ani do zestawów zarezerwowanych, ani niezarezerwowanych.

Typowe znaki po kodowaniu procentowym (oparte na ASCII lub UTF-8)
Nowa linia przestrzeń " % - . < > \ ^ _ ` { | } ~ £ 円
%0A lub %0D lub %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E %C2%A3 %E5%86%86

Dowolne dane znakowe są czasami kodowane procentowo i używane w sytuacjach innych niż identyfikatory URI, na przykład w programach do zaciemniania haseł lub innych protokołach translacji specyficznych dla systemu.

Aktualny standard

Główny artykuł: Międzynarodowy identyfikator zasobów

Ogólna składnia URI zaleca, aby nowe schematy URI, które zapewniają reprezentację danych znakowych w URI, reprezentowały znaki z niezarezerwowanego zestawu bez translacji i konwertowały wszystkie inne znaki na bajty zgodnie z UTF-8, a następnie procentami -koduj te wartości. Ta sugestia została wprowadzona w styczniu 2005 r. wraz z publikacją dokumentu RFC 3986. Nie dotyczy to schematów URI wprowadzonych przed tą datą.

Obecna specyfikacja nie dotyczy tego, co zrobić z zakodowanymi danymi znakowymi. Na przykład w komputerach dane znakowe manifestują się na pewnym poziomie w postaci zakodowanej, a zatem mogą być traktowane jako dane binarne lub znakowe podczas mapowania na znaki URI. Przypuszczalnie uwzględnienie tej możliwości i wymaganie jednego lub drugiego zależy od specyfikacji schematu URI, ale w praktyce niewielu, jeśli w ogóle, faktycznie to robi.

Niestandardowe wdrożenia

Istnieje niestandardowe kodowanie znaków Unicode: %u xxxx , gdzie xxxx to jednostka kodu UTF-16 reprezentowana jako cztery cyfry szesnastkowe. To zachowanie nie jest określone w żadnym dokumencie RFC i zostało odrzucone przez W3C. 13. wydanie ECMA-262 nadal zawiera funkcję ucieczki , która używa tej składni, która stosuje kodowanie UTF-8 do łańcucha, a następnie dokonuje procentowej ucieczki wynikowych bajtów.

Typ application/x-www-form-urlencoded

Po przesłaniu danych wprowadzonych do formularzy HTML nazwy i wartości pól formularza są kodowane i wysyłane do serwera w wiadomości żądania HTTP przy użyciu metody GET lub POST , lub historycznie za pośrednictwem poczty elektronicznej . Kodowanie używane domyślnie jest oparte na wczesnej wersji ogólnych reguł kodowania procentowego URI, z kilkoma modyfikacjami, takimi jak nowej linii i zamiana spacji na + zamiast %20 . Typ nośnika danych zakodowanych w ten sposób to application/x-www-form-urlencoded i jest obecnie zdefiniowany w specyfikacjach HTML i XForms . Ponadto CGI zawiera reguły dotyczące sposobu, w jaki serwery WWW dekodują dane tego typu i udostępniają je aplikacjom.

Gdy dane formularza HTML są wysyłane w żądaniu HTTP GET, są one uwzględniane w komponencie zapytania identyfikatora URI żądania przy użyciu tej samej składni, co opisana powyżej. W przypadku wysłania żądania HTTP POST lub wiadomości e-mail dane są umieszczane w treści wiadomości, a application/x-www-form-urlencoded jest dołączany do nagłówka Content-Type wiadomości.

Zobacz też

Linki zewnętrzne

Wszystkie poniższe specyfikacje omawiają i definiują znaki zastrzeżone, znaki niezarezerwowane i kodowanie procentowe w takiej czy innej formie:

Różne wdrożenia:

Pobrano z „ https://en.wikipedia.org/w/index.php?title=URL_encoding&oldid=1144465155 ”