Znaki dozwolone w adresie URL
Czy ktoś zna pełną listę znaków, które mogą być użyte w GET bez kodowania? W tej chwili używam A-Z a-Z i 0-9... ale szukam pełnej listy.
Jestem również zainteresowany, czy istnieje specyfikacja dla nadchodzącego dodatku Chińskich, Arabskich adresów url (ponieważ oczywiście będzie to miało duży wpływ na moje pytanie)
8 answers
Z RFC 1738 specyfikacja:
Zatem, tylko alfanumeryczne, znaki specjalne "
$-_.+!*'(),
", oraz znaki zastrzeżone używane do ich celów zastrzeżonych mogą być używane niekodowane w adresie URL.
EDIT: jak słusznie zauważył @Jukka K. Korpela, ten RFC został zaktualizowany przez RFC 3986 . To rozszerzyło i wyjaśniło znaki ważne dla hosta, niestety nie jest łatwo skopiować i wkleić, ale zrobię co w mojej mocy.
W pierwszym dopasowaniu kolejność:
host = IP-literal / IPv4address / reg-name
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ls32 = ( h16 ":" h16 ) / IPv4address
; least-significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
reg-name = *( unreserved / pct-encoded / sub-delims )
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" <---This seems like a practical shortcut, most closely resembling original answer
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
pct-encoded = "%" HEXDIG HEXDIG
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-04-02 21:36:11
Znaki URI mogą być zastrzeżone lub nieograniczone (lub znak procentowy jako część kodowania procentowego)
Http://en.wikipedia.org/wiki/Percent-encoding#Types_of_URI_characters
Mówi, że są to RFC 3986 znaki bezwarunkowe (sek. 2.3), jak również znaki zastrzeżone (sek. 2.2), jeśli muszą zachować swoje specjalne znaczenie. A także znak procentowy jako część kodowania procentowego.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-05-30 18:33:12
Pełna lista 66 niezerowych znaków znajduje się w RFC3986, tutaj: http://tools.ietf.org/html/rfc3986#section-2.3
Jest to dowolny znak w następującym zbiorze:
[A-Za-z0-9_.-~]
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-12-18 22:35:37
From here
Tak więc, tylko alfanumeryczne, znaki specjalne
$-_.+!*'(),
i zastrzeżone znaki używane do ich zastrzeżone cele mogą być używane bez kodu w adresie URL.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-11-18 02:32:19
[20]} Przetestowałem go, prosząc moją stronę (apache) o wszystkie dostępne znaki na mojej niemieckiej klawiaturze jako parametr URL: [21]}
http://example.com/?^1234567890ß´qwertzuiopü+asdfghjklöä#<yxcvbnm,.-°!"§$%&/()=? `QWERTZUIOPÜ*ASDFGHJKLÖÄ\'>YXCVBNM;:_²³{[]}\|µ@€~
Nie zostały zakodowane:
^0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,.-!/()=?`*;:_{}[]\|~
Nie zakodowane po urlencode()
:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_
Nie zakodowane po rawurlencode()
:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_~
Uwaga: Przed PHP 5.3.0 rawurlencode()
zakodowane ~
z powodu RFC 1738. Ale to zostało zastąpione przez RFC 3986 więc teraz jest bezpieczne w użyciu. Ale nie rozumiem, dlaczego np. {}
są kodowane przez rawurlencode()
ponieważ nie są wymienione w RFC 3986.
Dodatkowy test, który zrobiłem, dotyczył automatycznego linkowania w tekstach pocztowych. Testowałem Mozilla Thunderbird, aol.com, outlook.com, gmail.com, gmx.de oraz yahoo.de i w pełni połączyli adresy URL zawierające te znaki:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_~+#,%&=*;:@
Oczywiście ?
też było połączone, ale tylko jeśli zostało użyte raz.
Niektórzy sugerowaliby teraz używanie tylko znaków rawurlencode()
, ale czy słyszałeś kiedyś, że ktoś miał problemy z otwarciem tych znaków strony internetowe?
Asterisk
http://wayback.archive.org/web/*/http://google.com
Okrężnica
https://en.wikipedia.org/wiki/Wikipedia:About
Plus
https://plus.google.com / + google
przy znaku, dwukropku, przecinku i wykrzykniku
https://www.google.com/maps/place/USA/@36.2218457,...
Z tego powodu te znaki powinny być użyte bez kodu bez problemów. Oczywiście nie powinieneś używać &;
ze względu na sekwencje kodowania takie jak &
. Ten sam powód jest ważny dla %
, Jak to było używane do kodowania znaków w ogóle. I {[18] } ponieważ przypisuje wartość do nazwy parametru.
W końcu powiedziałbym, że jest ok, aby używać tych niekodowanych:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_~!+,*:@
Ale jeśli spodziewasz się losowo generowanych adresów URL, nie powinieneś używać .!
, ponieważ oznaczają one koniec zdania, a niektóre aplikacje pocztowe nie będą automatycznie łączyć ostatniego znaku adresu url. Przykład:
Visit http://example.com/foo=bar! !
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-04-02 09:45:10
Są one wymienione w RFC3986 . Zobacz Zebrane ABNF dla URI aby zobaczyć, co jest dozwolone gdzie i regex do parsowania/walidacji.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-06 22:20:33
Nadchodząca zmiana dotyczy chińskich, arabskich nazw domen, a nie Uri. Umiędzynarodowione URI są nazywane IRIs i są zdefiniowane w RFC 3987 . Jednak, powiedziawszy, że nie polecam tego robić samemu, ale poleganie na istniejącej, przetestowanej bibliotece, ponieważ istnieje wiele możliwości kodowania/dekodowania URI i tego, co jest uważane za bezpieczne przez specyfikację, w porównaniu z tym, co jest bezpieczne przez rzeczywiste użycie (przeglądarki).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-06 22:21:08
RFC3986 definiuje dwa zestawy znaków, których można użyć w URI:
-
Znaki Zastrzeżone:
:/?#[]@!$&'()*+,;=
Reserved = Gen-delims / sub-delims
Gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
Sub-delims ="!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
Celem znaków zastrzeżonych jest dostarczenie zestawu znaków oddzielających, które można odróżnić od innych danych w obrębie URI. Uri różniące się zamianą zastrzeżonego znaku na odpowiadający mu oktet zakodowany procentowo nie są równoważne.
-
Znaki Niezerowe:
A-Za-z0-9-_.~
= Alfa / cyfra/" -"/"." / "_" / "~"
Znaki, które są dozwolone w URI, ale nie mają zastrzeżonego celu, nazywane są nieograniczonymi.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-12-27 23:03:07