Devo davvero codificare "&" come "& amp;"?

Sto usando un &simbolo ' ' con HTML5 e UTF-8 nel mio sito <title>. Google mostra la e commerciale bene sui suoi SERP, così come tutti i browser nei loro titoli.

http://validator.w3.org mi sta dando questo:

e non ha iniziato un riferimento al personaggio. (e probabilmente avrebbe dovuto essere evaso come &.)

Devo davvero fare &?

Non mi preoccupo delle mie pagine di convalida per motivi di convalida, ma sono curioso di ascoltare le opinioni delle persone su questo e se è importante e perché.

Sì. Proprio come ha detto l'errore, in HTML, gli attributi sono #PCDATA che significa che sono analizzati. Ciò significa che è possibile utilizzare entità carattere negli attributi. L'uso &da solo è sbagliato e se non fosse per browser indulgenti e il fatto che si tratti di HTML non XHTML, interromperebbe l'analisi. Basta scappare come &e tutto andrebbe bene.

HTML5 ti consente di lasciarlo senza caratteri di escape, ma solo quando i dati che seguono non sembrano un riferimento di carattere valido. Tuttavia, è meglio sfuggire a tutte le istanze di questo simbolo piuttosto che preoccuparsi di quali dovrebbero essere e quali non devono essere.

Tieni presente questo punto; se non stai eseguendo l'escape & a & amp ;, è abbastanza male per i dati che crei (dove il codice potrebbe non essere valido), potresti anche non sfuggire ai delimitatori di tag, il che è un grosso problema per i dati inviati dall'utente, che potrebbe benissimo comportare l'iniezione di HTML e script, il furto di cookie e altri exploit.

Per favore, scappa dal tuo codice. Ti farà risparmiare un sacco di problemi in futuro.

Convalida a parte, resta il fatto che la codifica di alcuni caratteri è importante per un documento HTML in modo che possa essere visualizzato in modo corretto e sicuro come una pagina web.

La codifica &come &in tutte le circostanze, per me, è una regola più semplice da rispettare, riducendo la probabilità di errori e fallimenti.

Confronta quanto segue: quale è più facile? quale è più facile da incastrare ?

Metodologia 1

1. Scrivi del contenuto che includa caratteri e commerciale.
2. Codificali tutti.

Metodologia 2

(con un granello di sale, per favore;))

1. Scrivi del contenuto che include caratteri e commerciale.
2. Caso per caso, guarda ogni e commerciale. Determinare se:
   • È isolato e come tale inequivocabilmente una e commerciale. per esempio. volt & amp
      > In tal caso, non preoccuparti di codificarlo.
   • Non è isolato, ma ritieni che sia comunque inequivocabile, poiché l'entità risultante non esiste e non esisterà mai poiché l'elenco di entità non potrebbe mai evolversi. ad es. amp&volt
      > In tal caso, non preoccuparti di codificarlo.
   • Non è isolato e ambiguo. per esempio. volt&amp
      > Codificalo.

??

Le regole HTML5 sono diverse da HTML4. Non è richiesto in HTML5, a meno che la e commerciale non sembri che inizi un nome di parametro. "& copy = 2" è ancora un problema, ad esempio, poiché & copy; è il simbolo del copyright.

Tuttavia, mi sembra che sia più difficile decidere di codificare o non codificare a seconda del testo seguente. Quindi il percorso più semplice è probabilmente quello di codificare tutto il tempo.

Penso che questo si sia trasformato in più in una domanda sul "perché seguire le specifiche quando il browser non se ne cura". Ecco la mia risposta generalizzata:

Gli standard non sono una cosa "presente". Sono una cosa "futura". Se, come sviluppatori, seguiamo gli standard Web, è più probabile che i fornitori di browser implementino correttamente tali standard e ci avviciniamo a un Web completamente interoperabile, in cui non sono necessari hack CSS, rilevamento di funzionalità e rilevamento di browser. Dove non dobbiamo capire perché i nostri layout si rompono in un particolare browser o come aggirarli.

In particolare, se HTML5 non richiede l'uso di & amp; nella tua situazione specifica e stai utilizzando un doctype HTML5 (e ti aspetti anche che i tuoi utenti utilizzino browser compatibili con HTML5), quindi non c'è motivo di farlo.

Bene, se proviene dall'input dell'utente, allora assolutamente sì, per ovvi motivi. Pensa se questo stesso sito web non lo facesse: il titolo di questa domanda verrebbe visualizzato come ho davvero bisogno di codificare '&' come '&'?

Se è solo qualcosa del genere, a echo '<title>Dolce & Gabbana</title>';rigor di termini non è necessario. Sarebbe meglio, ma in caso contrario nessun utente noterà la differenza.

Potresti mostrarci qual è la tua titlerealtà? Quando invio

<!DOCTYPE html>
<html>
<title>Dolce & Gabbana</title>
<body>
<p>am i allowed loose & mpersands?</p>
</body>
</html>

a http://validator.w3.org/ - chiedendogli esplicitamente di utilizzare la modalità sperimentale HTML 5 - non ha lamentele riguardo al &s ...

In HTML a &segna l'inizio di un riferimento, sia di un riferimento di carattere che di un riferimento di entità . Da quel momento in poi il parser si aspetta un #denotazione di un riferimento a carattere o un nome di entità che indica un riferimento di entità, entrambi seguiti da a ;. Questo è il comportamento normale.

Ma se il nome di riferimento o solo l'apertura di riferimento &è seguita da uno spazio bianco o altri delimitatori desiderate ", ', <, >, &, il finale ;e anche un riferimento per rappresentare una piana &può essere omesso:

<p title="&amp;">foo &amp; bar</p>
<p title="&amp">foo &amp bar</p>
<p title="&">foo & bar</p>

Solo in questi casi ;è possibile omettere la desinenza o persino il riferimento stesso (almeno in HTML 4). Penso che HTML 5 richieda il finale ;.

Ma la specifica raccomanda di usare sempre un riferimento come il riferimento al carattere &o il riferimento all'entità &per evitare confusione:

Gli autori dovrebbero usare " &" (ASCII decimale 38) invece di " &" per evitare confusione con l'inizio di un riferimento di carattere (delimitatore aperto riferimento entità). Gli autori dovrebbero anche usare " &" nei valori degli attributi poiché i riferimenti ai caratteri sono consentiti nei valori degli attributi CDATA.

Se l'utente lo passa a te o verrà visualizzato in un URL, devi evitarlo.

Se appare in un testo statico su una pagina? Tutti i browser lo capiranno in entrambi i modi, non ti preoccupare molto, poiché funzionerà.

Aggiornamento (marzo 2020): il validatore W3C non si lamenta più della fuga degli URL.

Stavo verificando il motivo per cui l'URL dell'Immagine ha bisogno di scappare, quindi l'ho provato in https://validator.w3.org . La spiegazione è piuttosto carina. Sottolinea che anche gli URL devono essere salvati. [PS: Immagino che non sarà sottoposto a escape quando viene consumato poiché è necessario l'URL &. Qualcuno può chiarire?]

<img alt="" src="foo?bar=qut&qux=fop" />

Nel documento è stato trovato un riferimento all'entità, ma non è stato definito alcun riferimento con quel nome. Spesso ciò è causato dall'ortografia errata del nome di riferimento, dalla e commerciale non codificata o dall'interruzione del punto e virgola finale (;). La causa più comune di questo errore è la e commerciale non codificata negli URL come descritto dal WDG in "Ampersands negli URL". I riferimenti alle entità iniziano con una e commerciale (&) e terminano con un punto e virgola (;). Se vuoi usare una e commerciale letterale nel tuo documento, devi codificarla come "&" (anche all'interno degli URL!). Fare attenzione a terminare i riferimenti di entità con un punto e virgola o il riferimento di entità potrebbe essere interpretato in relazione al seguente testo. Inoltre, tieni presente che i riferimenti alle entità denominate fanno distinzione tra maiuscole e minuscole; Di & aelig; e æ sono personaggi diversi.

Sì, se possibile, dovresti provare a fornire un codice valido.

La maggior parte dei browser correggerà silenziosamente questo errore, ma c'è un problema a fare affidamento sulla gestione degli errori nei browser. Non esiste uno standard su come gestire un codice errato, quindi spetta a ciascun fornitore di browser provare a capire cosa fare di ogni errore e i risultati possono variare.

Alcuni esempi in cui è probabile che i browser reagiscano in modo diverso sono se si inseriscono elementi all'interno di una tabella ma al di fuori delle celle della tabella o se si annidano collegamenti uno all'interno dell'altro.

Per il tuo esempio specifico non è probabile che causi problemi, ma la correzione degli errori nel browser potrebbe, ad esempio, cambiare il browser dalla modalità conforme agli standard alla modalità stranezze, il che potrebbe far crollare completamente il layout.

Quindi, dovresti correggere errori come questo nel codice, se non altro, in modo da mantenere breve l'elenco degli errori nel validatore, in modo da poter individuare problemi più gravi.

Un paio di anni fa, abbiamo ricevuto un rapporto secondo cui una delle nostre app Web non veniva visualizzata correttamente in Firefox. Si è scoperto che la pagina conteneva un tag simile

<div style="..." ... style="...">

Di fronte a un attributo di stile ripetuto, IE combina entrambi gli stili, mentre Firefox ne utilizza solo uno, quindi il diverso comportamento. Ho cambiato il tag in

<div style="...; ..." ...>

e abbastanza sicuro, ha risolto il problema! La morale della storia è che i browser hanno una gestione più coerente di HTML valido rispetto a HTML non valido. Quindi, correggi già il tuo dannato markup! (O utilizzare HTML Tidy per risolverlo.)

se &viene utilizzato in HTML , dovresti evitarlo

Se &viene utilizzato nelle stringhe javascript, ad esempio an alert('This & that');o document.href, non è necessario utilizzarlo.

Se stai usando document.write, dovresti usarlo ad es document.write(<p>this &amp; that</p>)

Dipende dalla probabilità che un punto e virgola finisca vicino al tuo &, facendolo mostrare qualcosa di molto diverso.

Ad esempio, quando si ha a che fare con l'input degli utenti (ad esempio, se si include l'argomento fornito da un utente di un post sul forum nei tag del titolo), non si sa mai dove potrebbero essere inseriti punti e virgola casuali e potrebbe visualizzare casualmente entità strane. Quindi scappa sempre in quella situazione.

Per il tuo html statico, certo, potresti saltarlo, ma è così banale includere una corretta evasione, che non ci sono buoni motivi per evitarlo.

Se stai davvero parlando del testo statico

<title>Foo & Bar</title>

memorizzato in alcuni file sul disco rigido e servito direttamente da un server, quindi sì: probabilmente non deve essere salvato.

Tuttavia, poiché non v'è molto poco contenuto HTML al giorno d'oggi che è completamente statico, io aggiungo la seguente dichiarazione di non responsabilità che presuppone che il contenuto HTML è generato da qualche altra fonte (il contenuto del database, l'input dell'utente, risultato chiamata di servizio web, eredità risultato API,. ..):

Se non sfuggi a un semplice &, allora è probabile che tu non sfugga a &un  o a <b>o <script src="http://attacker.com/evil.js">o qualsiasi altro testo non valido. Ciò significherebbe che nella migliore delle ipotesi stai visualizzando i tuoi contenuti in modo errato e più probabilmente sei sospettabile di attacchi XSS .

In altre parole: quando stai già controllando e sfuggendo agli altri casi più problematici, allora non c'è quasi motivo di lasciare lo standalone non totalmente rotto ma ancora un po 'sospetto e senza escape.

non sono sicuro se questo sia utile a nessuno ... Ho combattuto per un po '... ecco una gloriosa regex che puoi usare per correggere tutti i tuoi collegamenti, javascript, contenuti. Ho dovuto gestire un sacco di contenuti legacy che nessuno voleva correggere.

Aggiungi questo al tuo override di rendering nella tua pagina principale o controllo:

Per favore, non darmi fuoco per averlo messo nel posto sbagliato

// remove the & from href="blaw?a=b&b=c" and replace with & 
//in urls - this corrects any unencoded & not just those in URL's
// this match will also ignore any matches it finds within <script> blocks AND
// it will also ignore the matches where the link includes a javascript command like
// <a href="javascript:alert{'& & &'}">blaw</a>
html = Regex.Replace(html, "&(?!(?<=(?<outerquote>[\"'])javascript:(?>(?!\\k<outerquote>|[>]).)*)\\k<outerquote>?)(?!(?:[a-zA-Z][a-zA-Z0-9]*|#\\d+);)(?!(?>(?:(?!<script|\\/script>).)*)\\/script>)", "&amp;", RegexOptions.Singleline | RegexOptions.IgnoreCase);

Il collegamento ha un discreto esempio di quando e perché potrebbe essere necessario per sfuggire &alla&

https://jsfiddle.net/vh2h7usk/1/

È interessante notare che ho dovuto sfuggire al personaggio per rappresentarlo correttamente nella mia risposta qui. Se dovessi usare l' opzione di esempio del codice integrato (dal pannello delle risposte), posso semplicemente digitare &e appare come dovrebbe. Ma se dovessi usare manualmente l' <code></code>elemento, allora devo scappare per rappresentarlo correttamente :)