W3C validatie fout: Illegal character in query component.
Ik heb een website waar ik de gegevens via vcf formaat kan importere via outlook/lotus notes enz.
Hoewel alles goed werkt krijg ik een fout op de w3c validatie (Illegal character in query component.)
<a href="vcf.php?firstname=Frans&lastname=Llllll&phone[]=01234567&adres=eenstraat%2030;Gent;;9000;Belgie">visitekaartje</a>
Kan iemand me zeggen welk karakter daar niet mag staan?
het is in html5
Jan
PS ik hoop dat deze vraag hier juist staat
Gewijzigd op 28/01/2013 11:40:31 door Jan R
Ik kom hieruit, als je het volgende vervangt:
phone[]=01234567
door:
phone=01234567
Is de error weg.
Misschien dat je het hiermee kan oplossen.
Jan R op 28/01/2013 07:19:30:
<a href="vcf.php?firstname=Frans&lastname=Llllll&phone[]=01234567&adres=eenstraat%2030;Gent;;9000;Belgie">visitekaartje</a>
<a href="vcf.php?firstname=Frans&lastname=Llllll&phone[]=01234567&adres=eenstraat%2030;Gent;;9000;Belgie">visitekaartje</a>
Volgens mij heb je de querystring door htmlspecialchars() gehaald en volgens mij moet dat juist niet want hier wil je echt een querystring hebben. Dus:
Ivo, nee dat is fout (al is het helemaal niet fout, maar de validator vind hem fout)
Beste Wouter, ik stel je commentaar altijd bijzonder op prijs. Maar dit keer ben je erg cryptisch. Kun je iets meer zeggen? Is het nu fout of niet of is de validator fout?
De [] moest blijven daar er meerdere mogelijkheden waren voor phone, gsm en email. Maar het stuurde me wel in de juiste richting.
gewoon veranderen naar: %5b%5D
Jan
Weer een probleem opgelost :)
(daar hoort ie ook thuis ;-) en gaan even kijken naar wat de specificaties voorschrijven voor URLs.
De nieuwste URI specificatie is RFC 3986, deze zegt:
Het gaat me nu eerst over het code blok. Hierin staat dat :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ',', ; en = reserved characters (gereserveerde tekens) zijn. Wat dat betekend wordt in het stukje erboven uitgelegd:
>> These characters are called "reserved" because they may (or may not) be defined as delimiters by
>> the generic syntax, by each scheme-specific syntax, or by the
>> implementation-specific syntax of a URI's dereferencing algorithm.
Ze zijn dus gereserveerd voor doeleinde van URLs. In ons geval zien weten we dat ? en & door GET requests gebruikt wordt om query (url) parameters aan te geven. GET is in dit geval een scheme en dus behoort het onder "scheme-specific syntax" en dus is het toegestaan deze voor dit doeleinde in de URLs te gebruiken. Maar, zo gaat hij verder, gebruik je het ergens anders voor dan moet je hem encode met de welbekende percentage encoding (denk maar aan %20 voor een spatie).
In dit geval ging het bij jou om het feit dat & & was. Dit is toegestaan en dit gaat werken, maar dit is helemaal niet de bedoeling. Dit is weer zo'n mankement van de validator, hij ziet de & en denkt: "Hé, die is gereserveerd, laat ik een error tonen!". Maar in deze context is dit gewoon volkomen terecht.
Offtopic:
Ik vind het dan ook nog vreemd dat de validator verwijst naar het omzetten van & in &, aangezien je deze als %26 zou moeten encoden, conform de voorgeschreven percentage-encoding.
Dan weer terug naar de topic starter. Deze vraagt of [ en ] in een url mogen voorkomen. Ik zeg nee, dat mag niet. Zoals je ziet zijn deze 2 characters ook reserved en dus mogen ze alleen voor bepaalde doeleinden gebruikt worden. Ik vind niet dat ze onder de zojuist genoemde omstandigheden vallen. In dit geval zouden ze dus als %5B (voor de [) en %5D (voor de ]) moeten worden gecodeerd.
[sidenote]
Merk op dat dit allemaal een beetje muggenziften is. Deze URL zal gewoon werken en ik zou er ook helemaal niet op gaan letten. Het is wellicht wel leuk om eens te weten :)
[/sidenote]
Ivo, tuurlijk. We gooien die validator in het donkere hoekje van de kamer De nieuwste URI specificatie is RFC 3986, deze zegt:
Quote:
2.2. Reserved Characters
URIs include components and subcomponents that are delimited by
characters in the "reserved" set. These characters are called
"reserved" because they may (or may not) be defined as delimiters by
the generic syntax, by each scheme-specific syntax, or by the
implementation-specific syntax of a URI's dereferencing algorithm.
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.
URIs include components and subcomponents that are delimited by
characters in the "reserved" set. These characters are called
"reserved" because they may (or may not) be defined as delimiters by
the generic syntax, by each scheme-specific syntax, or by the
implementation-specific syntax of a URI's dereferencing algorithm.
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.
Het gaat me nu eerst over het code blok. Hierin staat dat :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ',', ; en = reserved characters (gereserveerde tekens) zijn. Wat dat betekend wordt in het stukje erboven uitgelegd:
>> These characters are called "reserved" because they may (or may not) be defined as delimiters by
>> the generic syntax, by each scheme-specific syntax, or by the
>> implementation-specific syntax of a URI's dereferencing algorithm.
Ze zijn dus gereserveerd voor doeleinde van URLs. In ons geval zien weten we dat ? en & door GET requests gebruikt wordt om query (url) parameters aan te geven. GET is in dit geval een scheme en dus behoort het onder "scheme-specific syntax" en dus is het toegestaan deze voor dit doeleinde in de URLs te gebruiken. Maar, zo gaat hij verder, gebruik je het ergens anders voor dan moet je hem encode met de welbekende percentage encoding (denk maar aan %20 voor een spatie).
In dit geval ging het bij jou om het feit dat & & was. Dit is toegestaan en dit gaat werken, maar dit is helemaal niet de bedoeling. Dit is weer zo'n mankement van de validator, hij ziet de & en denkt: "Hé, die is gereserveerd, laat ik een error tonen!". Maar in deze context is dit gewoon volkomen terecht.
Offtopic:
Ik vind het dan ook nog vreemd dat de validator verwijst naar het omzetten van & in &, aangezien je deze als %26 zou moeten encoden, conform de voorgeschreven percentage-encoding.
Dan weer terug naar de topic starter. Deze vraagt of [ en ] in een url mogen voorkomen. Ik zeg nee, dat mag niet. Zoals je ziet zijn deze 2 characters ook reserved en dus mogen ze alleen voor bepaalde doeleinden gebruikt worden. Ik vind niet dat ze onder de zojuist genoemde omstandigheden vallen. In dit geval zouden ze dus als %5B (voor de [) en %5D (voor de ]) moeten worden gecodeerd.
[sidenote]
Merk op dat dit allemaal een beetje muggenziften is. Deze URL zal gewoon werken en ik zou er ook helemaal niet op gaan letten. Het is wellicht wel leuk om eens te weten :)
[/sidenote]
Wouter, dat is een perfecte uitleg. Dank je wel.
Ik begrijp je uitleg wel dus daar geen probleem.
als ik echter zoals je suggureerd de & vervang door %26 dan werken mijn urls niet meer. verder zijn de %5b en %5d wel vervangen en deze werken correct. dus ergens zit er toch iets raar in :)
is er iemand wie eens iets nuttig kan zeggen over topic: http://www.phphulp.nl/php/forum/topic/graag-onderzoek-voor-mijn-adressenlijst/88908/last/
Jan
Gewijzigd op 29/01/2013 18:12:20 door Jan R
Quote:
als ik echter zoals je suggureerd de & vervang door %26 dan werken mijn urls niet meer. verder zijn de %5b en %5d wel vervangen en deze werken correct. dus ergens zit er toch iets raar in :)
Nee hoor. Zoals ik al zei is de & gereserveerd voor het scheiden van GET parameters, je moet deze dus niet escapen (niet met %26 en niet met &)
slecht begrepen sorry :)