Ce caractere fac un URL invalid? (Programare, Validare, Url, Rfc3986)

bun a intrebat.

Ce caractere fac ca un URL să nu fie valid?

Sunt acestea URL-uri valide?

  • example.com/file[/].html
  • http://example.com/file[/].html

Comentarii

    48

  • Atunci când validați, trebuie să „gândiți întotdeauna pozitiv”: cereți „ceea ce este valabil”, orice altceva este invalid. Testarea în funcție de (puținele) caractere valide este mult mai sigură (și mai ușoară!) decât toate caracterele invalide posibile. –  > Por mfx.
  • În legătură cu acestea: Care este cea mai bună expresie regulată pentru a verifica dacă un șir de caractere este un URL valid? –  > Por DavidRR.
10 răspunsuri
Gumbo

În general, URI-urile așa cum sunt definite de RFC 3986 (a se vedea Secțiunea 2: Caractere) pot conține oricare dintre următoarele 84 de caractere:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=

Rețineți că această listă nu precizează unde pot apărea aceste caractere în URI.

Orice alt caracter trebuie să fie codificat cu codificarea procentuală (%hh). Fiecare parte a URI are restricții suplimentare cu privire la caracterele care trebuie să fie reprezentate de un cuvânt codificat în procente.

Comentarii

    33

  • (bineînțeles, lista de caractere nu precizează unde în uri pot apărea) – –  > Por Eamon Nerbonne.
  • 78

  • Iată un regex care va determina dacă întregul șir conține doar caracterele de mai sus: /^[!#$&-;=?-[]_a-z~]+$/ +$/ – –  > Por Leif Wickland.
  • 46

  • @techiferous, Da, am uitat să permit caracterele scăpate „%”. Ar fi trebuit să arate mai degrabă așa: /^([!#$&-;=?-[]_a-z~]|%[0-9a-fA-F]{2})+$/ A mai fost ceva ce ați constatat că ar fi trebuit să accepte? (Doar pentru a fi clar, acel regex verifică doar dacă șirul conține caractere URL valide, nu dacă șirul conține un URL bine format). –  > Por Leif Wickland.
  • @Timwi RFC 3986 spune: „Un octet codificat în procente este codificat ca un triplet de caractere, format din caracterul de procente „%” urmat de cele două cifre hexazecimale care reprezintă valoarea numerică a acelui octet.” De asemenea, se mai spune: „Deoarece caracterul procent („%”) servește ca indicator pentru octeții codificați în procente, acesta trebuie să fie codificat în procente ca „%25″ pentru ca acel octet să fie utilizat ca date într-un URI.” Am citit acest lucru ca spunând că un „%” poate apărea numai dacă este urmat de două cifre hexagonale. Cum interpretați dumneavoastră această afirmație? –  > Por Leif Wickland.
  • @Weeble Regex-ul meu a inclus aceste caractere folosind intervale. Între „&” și „;” și între „?” și „[” veți găsi toate acele caractere pe care nu le-ați văzut. –  > Por Leif Wickland.
JasonM1

Pentru a adăuga câteva clarificări și a răspunde direct la întrebarea de mai sus, există mai multe clase de caractere care cauzează probleme pentru URL-uri și URI-uri.

Există unele caractere care nu sunt permise și care nu ar trebui să apară niciodată într-un URL/URI, caractere rezervate (descrise mai jos) și alte caractere care pot cauza probleme în anumite cazuri, dar care sunt marcate ca fiind „neînțelepte” sau „nesigure”. Explicațiile privind motivele pentru care caracterele sunt restricționate sunt clar precizate în RFC-1738 (URL-uri) și RFC-2396 (URI-uri). Rețineți că cele mai noi RFC-3986 (actualizare la RFC-1738) definește construcția caracterelor permise într-un anumit context, dar specificația mai veche oferă o descriere mai simplă și mai generală a caracterelor care nu sunt permise, cu următoarele reguli.

Caractere US-ASCII excluse Caracterele nepermise în cadrul sintaxei URI:

   control     = <US-ASCII coded characters 00-1F and 7F hexadecimal>
   space       = <US-ASCII coded character 20 hexadecimal>
   delims      = "<" | ">" | "#" | "%" | <">

Caracterul „#” este exclus deoarece este utilizat pentru a delimita un URI de un identificator de fragment. Caracterul procentual „%” este exclus deoarece este utilizat pentru codificarea caracterelor evadate. Cu alte cuvinte, „#” și „%” sunt caractere rezervate care trebuie utilizate într-un context specific.

Lista caracterelor neavizate este permisă, dar poate cauza probleme:

   unwise      = "{" | "}" | "|" | "
 | "^" | "[" | "]" | "`"

Caractere care sunt rezervate în cadrul unei componente de interogare și/sau au o semnificație specială în cadrul unui URI/URL:

  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

Clasa de sintaxă „rezervată” de mai sus se referă la acele caractere care sunt permise în cadrul unui URI, dar care pot să nu fie permise în cadrul unei anumite componente a sintaxei generice URI. Caracterele din setul „rezervat” nu sunt rezervate în toate contextele.. Numele de gazdă, de exemplu, poate conține un nume de utilizator opțional, astfel încât ar putea fi ceva de genul ftp://[email protected]/ unde caracterul „@” are o semnificație specială.

Iată un exemplu de URL care are caractere nevalabile și nesigure (de exemplu, ‘$’, ‘[‘, ‘]’) și care ar trebui să fie codificate corespunzător:

http://mw1.google.com/mw-earth-vectordb/kml-samples/gp/seattle/gigapxl/$[level]/r$[y]_c$[x].jpg

Unele dintre restricțiile de caractere pentru URI și URL-uri depind de limbajul de programare. De exemplu, caracterul „|” (0x7C), deși este marcat doar ca fiind „nechibzuit” în specificațiile URI, va genera o eroare de tip „unwise”. URISyntaxException în limbajul Java java.net.URI astfel încât un URL de tipul http://api.google.com/q?exp=a|b nu este permis și trebuie codificat ca http://api.google.com/q?exp=a%7Cb dacă se utilizează Java cu o instanță de obiect URI.

Comentarii

  • Un răspuns excelent, complet, singurul care răspunde direct la întrebarea reală. Este posibil ca secțiunea rezervată să mai necesite o intervenție, de exemplu literalul ? este în regulă în secțiunea de interogare, dar imposibil înainte de aceasta, și nu cred că @ nu are ce căuta în niciuna dintre aceste liste. Oh, și în loc de %25 în ultimul șir, nu vrei să spui %7C? –  > Por Bob Stein.
  • Mulțumesc. Bună observație: %25 a fost o greșeală de scriere în exemplu. Am adăugat o notă de subsol la descrierea sintaxei „rezervate” direct din RFC-2396. –  > Por JasonM1.
  • Acest răspuns nu este rău, , dar există unele confuzii și erori. Inițial, confundați caracterele nepermise și caracterele rezervate (lucruri foarte diferite), faceți o distincție prea mare între caracterele „neînțelepte” și alte caractere nepermise (abandonate în RFC 3986 și irelevante din punct de vedere sintactic chiar și în RFC 2396) și prezentați în mod confuz o listă a tuturor caracterelor rezervate ca fiind lista rezervate „în cadrul unei componente de interogare”. –  > Por Mark Amery.
  • Mulțumesc, nu am vrut să grupez caracterele nepermise și cele rezervate ca fiind aceleași. Am actualizat răspunsul. Regulile din RFC-2396, deși mai vechi, sunt mai ușor de înțeles decât regulile actualizate din 3986. Răspunsul reflectă mai mult caracterele care ar putea fi problematice în general, mai degrabă decât contextul exact în care sunt permise sau interzise. –  > Por JasonM1.
  • Este de remarcat faptul că Tomcat, în versiunile recente (7.0.73+, 8.0.39+, 8.5.7+), a început să respingă cererile cu caractere din categoria „nechibzuit” cu erori HTTP 400: „Invalid character found in the request target. Caracterele valide sunt definite în RFC 7230 și RFC 3986” –  > Por Philip.
Mark Amery

Majoritatea răspunsurilor existente aici sunt nepractice, deoarece ignoră total utilizarea în lumea reală a unor adrese de genul:

Mai întâi, o digresiune terminologică. Ce înseamnă sunt aceste adrese? Sunt ele URL-uri valide?

Din punct de vedere istoric, răspunsul a fost „nu”. Conform RFC 3986, , din 2005, astfel de adrese nu sunt URI-uri (și, prin urmare, nu sunt URL-uri, deoarece URL-urile sunt un tip de URI-uri). Conform terminologiei standardelor IETF din 2005, ar trebui să le numim în mod corespunzător IRI (Internationalized Resource Identifiers), așa cum este definit în RFC 3987, care, din punct de vedere tehnic, nu sunt URI-uri, dar pot fi convertite în URI-uri prin simpla codificare procentuală a tuturor caracterelor non-ASCII din IRI.

Conform specificațiilor moderne, răspunsul este „da”. Site-ul WHATWG Living Standard clasifică pur și simplu tot ceea ce ar fi fost numit anterior „URI” sau „IRI” ca fiind „URL”. Acest lucru aliniază terminologia specificată la modul în care oamenii normali care nu au citit specificația folosesc cuvântul „URL”, care a fost unul dintre obiectivele specifice ale specificației. obiective ale specificației.

Ce caractere sunt permise în cadrul standardului WHATWG Living Standard?

Conform acestui nou înțeles al cuvântului „URL”, ce caractere sunt permise? În multe părți ale URL-ului, cum ar fi șirul de interogare și calea de acces, este permisă utilizarea de caractere arbitrare. „unități URL”, , care sunt

puncte de cod URL și octeți codificați în procente.

Ce sunt „puncte de cod URL”?

puncte de cod URL sunt alfanumerice ASCII, U+0021 (!), U+0024 ($), U+0026 (&), U+0027 (‘), U+0028 PARENTHESIS stâng, U+0029 PARENTHESIS drept, U+002A (*), U+002B (+), U+002C (,), U+002D (-), U+002E (. ), U+002F (/), U+003A (:), U+003B (;), U+003D (=), U+003F (?), U+0040 (@), U+005F (_), U+007E (~) și punctele de cod din intervalul U+00A0 până la U+10FFFD, inclusiv, cu excepția caracterelor de substituție și a celor fără caracter.

(Rețineți că lista de „puncte de cod URL” nu include %, , ci că %sunt permise în „unități de cod URL” dacă fac parte dintr-o secvență de codificare procentuală).

Singurul loc în care pot observa că specificațiile permit utilizarea oricărui caracter care este nu din acest set este în gazdă, , unde adresele IPv6 sunt încadrate în [ și ] caractere. Peste tot în URL, sunt permise fie unități URL, fie un set de caractere și mai restrictiv.

Ce caractere erau permise în vechile RFC-uri?

De dragul istoriei, și din moment ce nu este explorat pe deplin în alte părți ale răspunsurilor de aici, să examinăm ce era permis în cadrul perechii de specificații mai vechi.

În primul rând, avem două tipuri de RFC 3986 caractere rezervate:

  • :/?#[]@, , care fac parte din sintaxa generică pentru un URI definită în RFC 3986.
  • !$&'()*+,;=, , care nu fac parte din sintaxa generică a RFC, dar sunt rezervate pentru a fi utilizate ca și componente sintactice ale anumitor scheme URI. De exemplu, punctele și virgulele și virgulele sunt utilizate ca parte a sintaxei de URI-uri de date, , și & și = sunt utilizate ca parte a omniprezentului simbol ?foo=bar&qux=baz în șirurile de interogare (care nu este specificat de RFC 3986).

Oricare dintre caracterele rezervate de mai sus poate fi utilizat în mod legal într-un URI fără codificare, fie pentru a servi scopului lor sintactic, fie doar ca caractere literale în date, în anumite locuri în care o astfel de utilizare nu ar putea fi interpretată greșit ca fiind caracterul care servește scopului său sintactic. (De exemplu, deși / are o semnificație sintactică într-un URL, îl puteți utiliza necodificat într-un șir de interogare, deoarece nu are semnificație într-un șir de interogare).

RFC 3986 specifică, de asemenea, câteva nerezervate care pot fi utilizate întotdeauna pentru a reprezenta pur și simplu date fără codificare:

  • abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~

În cele din urmă, caracterele % caracterul în sine este permis pentru codificări procentuale.

Astfel, rămân doar următoarele caractere ASCII care sunt interzise să apară într-un URL:

  • Caracterele de control (caracterele 0-1F și 7F), inclusiv linia nouă, tabularea și revenirea la cărucior.
  • "<>^`{|}

Toate celelalte caractere ASCII pot apărea în mod legal într-un URL.

Apoi, RFC 3987 extinde acest set de caractere nerezervate cu următoarele intervale de caractere Unicode:

  %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD

Aceste alegeri de blocuri din vechea specificație par bizare și arbitrare, având în vedere cele mai recente Unicode definiții de blocuri; acest lucru se datorează probabil faptului că blocurile au fost adăugate în deceniul care a trecut de la scrierea RFC 3987.


În cele din urmă, poate că merită remarcat faptul că simpla cunoaștere a caracterelor care pot apărea în mod legal într-un URL nu este suficientă pentru a recunoaște dacă un anumit șir de caractere este un URL legal sau nu, deoarece unele caractere sunt legale doar în anumite părți ale URL-ului. De exemplu, caracterele rezervate [ și ] sunt legale ca parte a unei gazde literale IPv6 într-un URL de tipul http://[1080::8:800:200C:417A]/foo dar nu sunt legale în niciun alt context, astfel încât exemplul lui OP de http://example.com/file[/].html este ilegal.

Comentarii

  • plusone pentru referințe exhaustive (de exemplu, RFC) –  > Por Yan Foto.
  • "<>^`{|} nu sunt interzise, ci sunt marcate ca nesigure. Dar aceste caractere sunt adesea utilizate în lumea reală. –  > Por puchu.
  • @puchu nu, ele sunt interzise. Denumirea „unsafe” nu a mai fost folosită pentru aceste caractere de la RFC 1738 (publicat în 1994 și deja depășit de RFC 2368 cu peste două decenii în urmă), și chiar și acolo, era doar un sinonim ciudat pentru „interzis”; RFC 1738 spunea că „Toate caracterele nesigure trebuie să fie fi întotdeauna codificate în cadrul unui URL”. (sublinierea îmi aparține). –  > Por Mark Amery.
  • Poate că aceste simboluri sunt interzise de unele rfc perfective, dar ele nu sunt codificate în lumea reală și sunt folosite adesea ca atare de către clienții și serverele vechi. –  > Por puchu.
  • Am găsit mai multe servere web care utilizează u007F (delete) caracter în url. Dar nu sunt 100% sigur că nu sunt ceva de genul honeypots sparte. –  > Por puchu.
Dominic Sayers

În întrebarea dumneavoastră suplimentară ați întrebat dacă www.example.com/file[/].html este un URL valid.

Acel URL nu este valid, deoarece un URL este un tip de URI și un URI valid trebuie să aibă o schemă de tipul http: (vezi RFC 3986).

Dacă ați vrut să întrebați dacă http://www.example.com/file[/].html este o adresă URL validă, răspunsul este tot nu, deoarece caracterele de paranteză pătrată nu sunt valide.

Caracterele de paranteză pătrată sunt rezervate pentru URL-uri în acest format: http://[2001:db8:85a3::8a2e:370:7334]/foo/bar (adică un literal IPv6 în loc de un nume de gazdă)

Merită să citiți cu atenție RFC 3986 dacă doriți să înțelegeți pe deplin această problemă.

Comentarii

  • După ce am citit RFC-ul, sunt mai înclinat să fiu de acord cu explicația mai detaliată a lui @Stephen C. –  > Por skolima.
  • A URL-urile nu sunt un subset al URI. [ și ] nu sunt valide pentru URI pentru aproape toate analizoarele pe care le-am văzut. Acest lucru m-a înșelat de fapt în lumea reală: stackoverflow.com/questions/11038967/…  > Por Adam Gent.
  • @AdamGent URL-urile sunt foarte mult un subset de URI-uri. Singura diferență dintre ele este dacă descriu sau nu locația resursei – care este o distincție semantică, nu una sintactică. Dacă analizoarele pe care le-ați văzut și care s-au etichetat ca analizoare „URI” au tratat parantezele pătrate în mod diferit față de cele care s-au etichetat ca analizoare „URL”, atunci aceasta este o pură coincidență, nu este cauzată de vreo diferență între URL-uri și URI-uri. –  > Por Mark Amery.
  • @Mark Amery este analog cu a spune că C++ este un superset al C. Este în mare parte, dar nu este în întregime adevărat, deoarece (URL și C) este mult mai vechi și trebuie să includă un comportament mai puțin strict. Problema este că analizatorii de URL-uri vor analiza lucruri care nu sunt URI-uri valide… Și mă refer la cele mai multe dintre ele (sincer, am obosit să subliniez acest lucru în atât de multe limbaje) Nu este o coincidență, ci compatibilitate retroactivă. Putem fi de acord că specificația URL este mai veche, cel puțin? –  > Por Adam Gent.
  • @MarkAmery Asta este de la Python, C#, Java și unele biblioteci C pe care parserii le vor lua Unwise foarte în serios pentru URI-uri și totuși să fie în regulă cu bibliotecile URL. Adică nu există niciun steag pentru a ignora Unwise. Va trebui să verific ce Rust lang (din moment ce este construit pentru un browser sunt curios ce face) pentru URL-uri. Majoritatea browserelor însă vor trece cu plăcere și „[„, „]”. Deci, în teorie, așa cum am spus cu C/C++, acestea sunt sub/super, dar realitatea nu este atât de adevărată. Aceasta depinde în mare măsură de interpretarea specificațiilor și de semantica super/subset. –  > Por Adam Gent.
CraigTP

Toate valabile care pot fi utilizate într-un URI (un URL este un tip de URI) sunt definite în RFC 3986.

Toate celelalte caractere pot fi utilizate într-un URL, cu condiția ca acestea să fie mai întâi „URL Encoded”. Acest lucru implică schimbarea caracterului invalid cu „coduri” specifice (de obicei sub forma simbolului procentual (%) urmat de un număr hexazecimal).

Acest link, HTML URL Encoding Reference, , conține o listă a codificărilor pentru caracterele invalide.

Comentarii

  • Și pentru Unicode articolul din Wikipedia Codificarea procentuală spune următoarele: „Sintaxa URI generică impune ca noile scheme URI care prevăd reprezentarea datelor de caractere într-un URI să reprezinte, de fapt, caracterele din setul nerezervat fără traducere, și trebuie să convertească toate celelalte caractere în octeți în conformitate cu UTF-8, iar apoi să codifice aceste valori în procente..” –  > Por DavidRR.
Ciro Santilli新疆棉花TRUMP BAN BAD

Mai multe dintre intervalele de caractere Unicode sunt valide în HTML5, , deși s-ar putea să nu fie totuși o idee bună să le folosiți.

De exemplu, href docs spune http://www.w3.org/TR/html5/links.html#attr-hyperlink-href:

Atributul href de pe elementele a și area trebuie să aibă o valoare care să fie un URL valid, potențial înconjurat de spații.

În acest caz, definiția „URL-ului valid” indică http://url.spec.whatwg.org/, , care spune că are ca scop:

Alinierea RFC 3986 și RFC 3987 cu implementările contemporane și, în acest proces, să le facă caduce.

Acest document definește punctele de cod URL ca:

ASCII alfanumeric, „!”, „$”, „&”, „‘”, „(„, „)”, „*”, „+”, „,”, „-„, „.”, „/”, „:”, „;”, „=”, „? „, „@”, „_”, „~” și punctele de cod din intervalele U+00A0 până la U+D7FF, U+E000 până la U+FDCF, U+FDF0 până la U+FFFD, U+10000 până la U+1FFFD, U+20000 până la U+2FFFD, U+30000 până la U+3FFFD, U+40000 până la U+4FFFD, U+50000 până la U+5FFFD, U+60000 până la U+6FFFD, U+70000 până la U+7FFFD, U+80000 până la U+8FFFD, U+90000 până la U+9FFFD, U+A0000 până la U+AFFFD, U+B0000 până la U+BFFFD, U+C0000 până la U+CFFFD, U+D0000 până la U+DFFFFD, U+E1000 până la U+EFFFD, U+F0000 până la U+FFFFFFD, U+100000 până la U+10FFFD.

Termenul „puncte de cod URL” este apoi utilizat în declarație:

Dacă c nu este un punct de cod URL și nu este „%”, eroare de analiză.

în mai multe părți ale algoritmului de analiză, inclusiv schema, autoritatea, calea relativă, interogarea și stările de fragmente: deci, practic, întregul URL.

De asemenea, validatorul http://validator.w3.org/ trece pentru URL-uri precum "你好", , și nu trece pentru URL-uri cu caractere precum spații "a b"

Desigur, așa cum a menționat Stephen C, nu este vorba doar de caractere, ci și de context: trebuie să înțelegeți întregul algoritm. Dar, din moment ce clasa „puncte de cod URL” este utilizată în punctele cheie ale algoritmului, aceasta oferă o idee bună despre ce se poate utiliza sau nu.

A se vedea, de asemenea: Caractere Unicode în URL-uri

Bunyk

Am nevoie să selectez caracterul pentru a împărți urile în șiruri, așa că am decis să creez o listă de caractere care nu au putut fi găsite în URL de către mine:

>>> allowed = "-_.~!*'();:@&=+$,/?%#[][email protected]"
>>> from string import printable
>>> ''.join(set(printable).difference(set(allowed)))
'`" <x0b
rx0c\t{^}|>'

Deci, alegerile posibile sunt newline, tab, spațiu, backslash și "<>{}^|. Cred că voi alege spațiul sau newline 🙂

ChrisR

Nu este chiar un răspuns la întrebarea ta, dar validarea url-urilor este într-adevăr un p.i.t.a. Ești probabil mai bine să validezi numele de domeniu și să lași partea de interogare a url-ului. Aceasta este experiența mea.Ai putea, de asemenea, să recurgi la ping la url și să vezi dacă rezultă un răspuns valid, dar asta ar putea fi prea mult pentru o sarcină atât de simplă.

Expresii regulate pentru a detecta url-urile sunt din belșug, căutați pe Google 🙂

Comentarii

  • În legătură cu aceasta: Care este cea mai bună expresie regulată pentru a verifica dacă un șir de caractere este un URL valid? –  > Por DavidRR.
  • Acest răspuns sfătuiește că validarea URL-urilor este o treabă nu pentru un regex, ci pentru un bibliotecă specifică limbajului/platformei. –  > Por DavidRR.
puchu

Implementez vechiul http (0.9, 1.0, 1.1) cititor / scriitor de cereri și răspunsuri http (0.9, 1.0, 1.1). Request URI este locul cel mai problematic.

Nu poți folosi doar RFC 1738, 2396 sau 3986 așa cum este. Există mulți clienți și servere HTTP vechi care permit mai multe caractere. Așa că am făcut cercetări bazate pe jurnalele de acces ale serverelor web publicate accidental: "GET URI HTTP/1.0" 200.

Am constatat că următoarele caractere non-standard sunt adesea folosite în URI:

 { } < > | ` ^ "

Aceste caractere au fost descrise în RFC 1738 ca fiind nesigure.

Dacă doriți să fiți compatibil cu toți clienții și serverele HTTP vechi – trebuie să permiteți aceste caractere în URI-ul cererii.

Vă rugăm să citiți mai multe informații despre această cercetare în oghttp-request-collector.

Comentarii

  • Există vreun API pentru a elimina aceste caractere dintr-un șir de caractere –  > Por Sandeep Das.
relipse

Am venit cu câteva expresii regulate pentru PHP care vor converti urile din text în etichete de ancorare. (În primul rând, convertește toate urile www. în http:// apoi convertește toate urile cu https?:// în linkuri html href=… html

$string = preg_replace('/(https?://)([!#$&-;=?-[]_a-z~%]+)/sim', '<a href="$1$2">$2</a>',
preg_replace('/(s)((www.)([!#$&-;=?-[]_a-z~%]+))/sim', '$1http://$2', $string)
);

Comentarii

  • -1; dincolo de faptul că ambele implică URL-uri într-o anumită capacitate, acest lucru nu are nimic de-a face cu întrebarea care a fost pusă. –  > Por Mark Amery.