Codifico le e commerciali in <a href…>?

157

Sto scrivendo codice che genera automaticamente HTML e voglio che codifichi le cose correttamente.

Supponiamo che sto generando un collegamento al seguente URL:

http://www.google.com/search?rls=en&q=stack+overflow

Suppongo che tutti i valori degli attributi debbano essere codificati in HTML. (Per favore, correggimi se sbaglio.) Ciò significa che se inserisco l'URL sopra in un tag anchor, dovrei codificare la e commerciale come &, in questo modo:

<a href="http://www.google.com/search?rls=en&amp;q=stack+overflow">

È corretto?

html

— JW.
fonte

possibile duplicato di Quali caratteri rendono non valido un URL?

— Ciro Santilli 29 冠状病六四事件法轮功

6

@CiroSantilli: si tratta di stringhe URL effettive; si tratta di come vengono codificati quando compaiono negli attributi HTML.

— JW.

come vedo, la codifica e commerciale non è sempre richiesta in HTML5 e le risposte non sono aggiornate.

— Qdinar,

1

domanda per HTML5: stackoverflow.com/questions/19441750/...

— qdinar

175

Sì. Le entità HTML vengono analizzate all'interno degli attributi HTML e un randagio &creerebbe un'ambiguità. Ecco perché dovresti sempre scrivere &invece che &all'interno di tutti gli attributi HTML.

Detto questo, solo &e le virgolette devono essere codificate. Se hai caratteri speciali come énel tuo attributo, non è necessario codificarli per soddisfare il parser HTML.

In passato era necessario che gli URL richiedessero un trattamento speciale con caratteri non ASCII, come é. Bisognava codificare quelli che usavano la percentuale di escape, e in questo caso avrebbe dato %C3%A9, perché erano definiti da RFC 1738 . Tuttavia, RFC 1738 è stato sostituito da RFC 3986 (URI, Uniform Resource Identifiers) e RFC 3987 (IRIs, Internationalized Resource Identifier), su cui WhatWG ha basato il suo lavoro per definire come i browser dovrebbero comportarsi quando vedono un URL con non-ASCII caratteri in esso da HTML5 . È quindi ora sicuro includere caratteri non ASCII negli URL, codificati in percentuale o meno.

— zneak
fonte

1

Ne ero abbastanza sicuro, ma avevo un raro momento di dubbio. Grazie per la conferma.

— JW.

1

Puoi anche codificare gli spazi come "+" anziché% 20, il che semplifica la lettura dell'URL.

— NickG

1

+ non è attualmente rispettato nei collegamenti mailto nel client di posta nativo iPhone, per quello che vale.

— Ryan Olson,

1

éha ancora bisogno di codifica: stackoverflow.com/questions/2742852/unicode-characters-in-urls

— lulalala

4

Aggiungerei (visto che sono appena caduto in questo errore) che se fai affidamento su un motore di template dovresti controllare se questo si occupa automaticamente di sfuggire alle entità HTML o meno. Nel mio caso Twig lo stava facendo e stavo erroneamente scappando doppiamente scrivendo &nell'attributo tag invece di usarlo direttamente &.

— Kamafeather,

24

Secondo le attuali raccomandazioni HTML ufficiali, la e commerciale deve essere sfuggita, ad esempio come &in contesti come questo. Tuttavia, i browser non lo richiedono e la CR HTML5 propone di renderlo una regola , in modo che vengano applicate regole speciali nei valori degli attributi. I validatori HTML5 attuali sono obsoleti a questo proposito (vedere la segnalazione di bug con commenti).

Rimarrà possibile sfuggire alla e commerciale nei valori degli attributi, ma a parte la convalida con gli strumenti attuali, non c'è alcuna necessità pratica di sfuggirli ai hrefvalori (e c'è un piccolo rischio di commettere errori se si inizia a sfuggirli ).

— Jukka K. Korpela
fonte

4

Tuttavia, XHTML (XHTML reale inviato come application/xhtml+xml) molto probabilmente lo richiederà sempre.

— zneak,

4

Un avvertimento a questo cambiamento, che è ancora in discussione, dibattuto e frainteso, è che ora &si suppone che vada bene, purché sia " non ambiguo". Un modo ovvio per rendere ambigua la e commerciale è seguirlo prima con caratteri non spaziali e poi un punto e virgola. Quella commerciale è ora ambiguo, e verrà causare un errore di analisi.

— matty,

Come ha detto Jukka, c'è sicuramente il rischio di codificare tutte le e commerciali, quindi considera quanto è probabile che uno dei tuoi href urls contenga un punto e virgola. Piuttosto improbabile, poiché non sono sicuro di aver mai visto un url con un punto e virgola. Non che non si possa fare. Quindi, in pratica, non credo sia probabile che il nostro uso di &sarà ambiguo. Pertanto, continuiamo a usarlo non codificato negli attributi href.

— matty,

L'intera ragione per cui la fuga è necessaria è proprio a causa della possibilità di un'ambiguità . Questo particolare problema potrebbe non introdurre i vettori di attacco XSS, il rendering errato o qualsiasi effetto del 99,99% delle volte, ma non è un motivo per non disturbare. Fare una fuga corretta è difficile e c'è sempre la possibilità di commettere errori.

— Phil

5

Sto pubblicando una nuova risposta perché trovo che la risposta di zneak non abbia abbastanza esempi, non mostri la gestione di HTML e URI come aspetti e standard diversi e manchi alcune cose minori.

Hai due standard riguardanti gli URL nei link ( <a href).

Il primo standard è RFC 1866 (HTML 2.0) dove in "3.2.1. Caratteri dati" è possibile leggere i caratteri che devono essere salvati quando utilizzati come valore per un attributo HTML. (Gli attributi stessi non consentono affatto caratteri speciali, ad es. <a hr&ef="http://...Non è consentito, né lo è <a hr&ef="http://....)

Successivamente questo è entrato nello standard HTML 4 , i caratteri che devi scappare sono:

<   to   &lt;
>   to   &gt;
&   to   &amp;
"   to   &quote;
'   to   &apos;

L'altro standard è RFC 3986 "Standard URI generico", in cui vengono gestiti gli URL (ciò accade quando il browser sta per seguire un collegamento perché l'utente ha fatto clic sull'elemento HTML).

reserved    = gen-delims / sub-delims

gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims  = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

È importante sfuggire a quei caratteri in modo che il client sappia se rappresentano dati o un delimitatore.

Esempio senza caratteri di escape:

https://example.com/?user=test&password&te&st&goto=https://google.com

Esempio, URL completamente legittimo

https://example.com/?user=test&password&te%26st&goto=https%3A%2F%2Fgoogle.com

Esempio di URL completamente legittimo in valore dell'attributo HTML:

https://example.com/?user=test&amp;password&amp;te%26st&amp;goto=https%3A%2F%2Fgoogle.com

Anche scenari importanti:

Javascript come valore:

<img src="..." onclick="window.location.href = "https://example.com/?user=test&password&te%26st&goto=https%3A%2F%2Fgoogle.com";">...</a>(Sì, ;;è corretto.)
JSON come valore:

<a href="..." data-analytics="{"event": "click"}">...</a>
Elementi di escape in oggetti di escape, doppia codifica, URL all'interno di URL all'interno di parametri ecc., ...

http://x.com/?passwordUrl=http%3A%2F%2Fy.com%2F%3Fuser%3Dtest&password=""123

— Daniel W.
fonte

3

Sì, dovresti convertirlo &in &.

Questo strumento di validazione html di W3C è utile per domande come questa. Ti dirà gli errori e gli avvisi per una determinata pagina.

— Randy Greencorn
fonte

1

Non sono sicuro che il validatore W3C rilevi questo (senza caratteri di escape &in un href) come errore.

— ChrisW,

6

Attualmente, il validatore W3C accetta non escape e come valido. Significa che lo standard è cambiato e la codifica non è più necessaria? (rendendo la maggior parte delle risposte qui obsolete)? In tal caso, questo vale solo per href o qualsiasi attributo?

— matteo,