it-swarm.dev

Eu realmente preciso codificar '&' como '& amp;'?

Estou usando um símbolo '&' com HTML5 e UTF-8 no <title> do meu site. O Google mostra o "fine" comercial em seus SERPs, assim como todos os navegadores em seus títulos.

http://validator.w3.org está me dando isto:

& não iniciou uma referência de caracteres. (e provavelmente deveria ter escapado como &amp;.)

Eu realmente preciso fazer &amp;?

Não estou preocupado com a validade das minhas páginas para validar, mas estou curioso para ouvir as opiniões das pessoas sobre isso e se é importante e por quê.

191
Haroldo

Sim. Assim como o erro dizia, em HTML, os atributos são #PCDATA, ou seja, eles são analisados. Isso significa que você pode usar entidades de caractere nos atributos. Usando & por si só está errado e se não fosse para navegadores brandos e o fato de que isso é HTML não XHTML, iria quebrar a análise. Apenas escape como &amp; e tudo ficaria bem.

O HTML5 permite deixá-lo sem escape, mas apenas quando os dados que seguem não se parecem com uma referência de caracteres válida. Entretanto, é melhor apenas escapar de todas as instâncias deste símbolo do que se preocupar com quais devem ser e quais não precisam ser.

Mantenha este ponto em mente; Se você não estiver escapando de & para & amp ;, é ruim o suficiente para os dados que você criar (onde o código pode muito bem ser inválido), você também pode não estar escapando dos delimitadores de tags, o que é um grande problema para os dados enviados pelos usuários. que poderia muito bem levar a injeção de HTML e script, roubo de cookies e outras explorações.

Por favor, apenas escape do seu código. Isso vai lhe poupar muitos problemas no futuro.

134
Delan Azabani

Deixando de lado a validação, a verdade é que a codificação de certos caracteres é importante para um documento HTML, de modo que ele possa ser processado de forma adequada e segura como uma página da web.

Codificar & como &amp; em todas as circunstâncias, para mim, é uma regra mais fácil de se viver, reduzindo a probabilidade de erros e falhas.

Compare o seguinte: o que é mais fácil? o que é mais fácil para vomitar?

Metodologia 1

  1. Escreva algum conteúdo que inclua caracteres de e comercial.
  2. Codifique todos eles.

Metodologia 2

(com um grão de sal, por favor;))

  1. Escreva algum conteúdo que inclua caracteres de e comercial.
  2. Em uma base caso a caso, olhe para cada e comercial. Determine se:
    • É isolado e, como tal, inequivocamente um "e" comercial. por exemplo. volt & amp
      > Nesse caso, não se incomode em codificá-lo.
    • Não é isolado, mas você sente que não deixa de ser inequívoco, pois a entidade resultante não existe e nunca existirá, uma vez que a lista de entidades nunca poderia evoluir. eg amp&volt
      > Nesse caso, não se incomode em codificá-lo.
    • Não é isolado e ambíguo. por exemplo. volt&amp
      > Codifique.

??

51
Richard JP Le Guen

Eu pesquisei isso completamente e escrevi sobre minhas descobertas aqui: http://mathiasbynens.be/notes/ambiguous-ampersands

Eu também criei ma ferramenta on-line que você pode usar para verificar sua marcação de e-mails ambíguos ou referências de caracteres que não terminam com um ponto-e-vírgula, ambos inválidos. (Nenhum validador HTML atualmente faz isso corretamente.)

http://i.imgur.com/cLssU.png

31
Mathias Bynens

As regras de HTML5 são diferentes do HTML4. Não é necessário em HTML5 - a menos que o "e" comercial pareça iniciar um nome de parâmetro. "& copy = 2" ainda é um problema, por exemplo, uma vez que & copy; é o símbolo de direitos autorais.

No entanto, parece-me que é mais difícil decidir codificar ou não a codificação, dependendo do texto a seguir. Portanto, o caminho mais fácil é provavelmente codificar o tempo todo.

19
Matthew Wilson

Acho que isso se tornou mais uma questão de "por que seguir a especificação quando o navegador não se importa". Aqui está minha resposta generalizada:

Padrões não são uma coisa "presente". Eles são uma coisa "futura". Se nós, como desenvolvedores, seguimos os padrões da web, então os fornecedores de navegadores estão mais propensos a implementar corretamente esses padrões, e nos aproximamos de uma Web completamente interoperável, onde hacks de CSS, detecção de recursos e detecção de navegador não são necessários. Onde não precisamos descobrir por que nossos layouts estão em um navegador específico ou como resolver isso.

Especificamente, se o HTML5 não exigir o uso de & amp; em sua situação específica, e você está usando um tipo de documento HTML5 (e também esperando que seus usuários usem navegadores compatíveis com HTML5), não há motivo para isso.

13
Ryan Kinal

Bem, se vem de entrada do usuário, então sim, por razões óbvias. Pense se este site não o fez: o título desta pergunta apareceria como preciso realmente codificar "&" como "&"?

Se é apenas algo como echo '<title>Dolce & Gabbana</title>';, então, estritamente falando, você não precisa. Seria melhor, mas se você não fizer, nenhum usuário notará a diferença.

5
Thomas Bonini

Você poderia nos mostrar qual é o seu title? Quando eu submeto

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

to http://validator.w3.org/ - pedindo explicitamente que use o modo experimental HTML 5 - sem queixas sobre o &s ...

5
AakashM

Em HTML, um & marca o início de uma referência, seja de referência de caractere ou de uma referência de entidade . A partir desse ponto, o analisador espera que um # denote uma referência de caractere ou um nome de entidade que indique uma referência de entidade, ambos seguidos por ;. Esse é o comportamento normal.

Mas se o nome de referência ou apenas a abertura de referência & for seguida por um espaço em branco ou outros delimitadores como ", ', <, >, &, o final ; e até mesmo uma referência para representar um & simples podem ser omitidos:

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

Somente nesses casos o final ; ou mesmo a própria referência pode ser omitida (pelo menos em HTML 4). Acho que o HTML 5 exige o final ;.

Mas o especificação recomenda para sempre usar uma referência como a referência de caracteres &#38; ou a referência de entidade &amp; para evitar confusão:

Os autores devem usar "&amp;" (decimal ASCII 38) em vez de "&" para evitar confusão com o início de uma referência de caractere (delimitador aberto de referência de entidade). Os autores também devem usar "&amp;" nos valores dos atributos, uma vez que as referências de caracteres são permitidas nos valores dos atributos CDATA.

4
Gumbo

Se o usuário passar para você, ou ele vai acabar em um URL, você precisa escapar.

Se aparecer em texto estático em uma página? Todos os navegadores obterão este direito de qualquer forma, você não se preocupa muito com isso, já que funcionará.

3
Dean J

Há alguns anos, recebemos um relatório dizendo que um de nossos aplicativos da Web não estava sendo exibido corretamente no Firefox. Acontece que a página continha uma tag que parecia

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

Quando confrontado com um atributo de estilo repetido, IE combina ambos os estilos, enquanto o Firefox usa apenas um deles, daí o comportamento diferente. Eu mudei a tag para

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

e com certeza, resolveu o problema! A moral da história é que os navegadores têm um tratamento mais consistente de HTML válido do que de HTML inválido. Então, conserte sua maldita marcação já! (Ou use o HTML Tidy para consertá-lo.)

2
dan04

Sim, você deve tentar fornecer um código válido, se possível.

A maioria dos navegadores corrige silenciosamente esse erro, mas há um problema em confiar no tratamento de erros nos navegadores. Não há um padrão para como lidar com códigos incorretos, então cabe a cada fornecedor de navegador tentar descobrir o que fazer com cada erro, e os resultados podem variar.

Alguns exemplos em que os navegadores provavelmente reagem de maneira diferente são se você colocar elementos dentro de uma tabela, mas fora das células da tabela, ou se você aninhar os links dentro uns dos outros.

Para o seu exemplo específico, não é provável que cause problemas, mas a correção de erros no navegador pode, por exemplo, fazer com que o navegador mude do modo compatível com os padrões para o modo quirks, o que poderia fazer com que seu layout se desmoronasse completamente.

Assim, você deve corrigir erros como este no código, se não for para mais nada, para manter a lista de erros no validador curta, para que você possa detectar problemas mais sérios.

2
Guffa

Eu estava verificando por que o URL da imagem precisava ser evitado, portanto tentei em https://validator.w3.org . A explicação é bem legal. Ele destaca que até mesmo os URLs precisam ser ignorados. [PS: Eu acho que não sairá de cena quando for consumido, já que a URL precisa de &. Alguém pode esclarecer?]

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

Uma referência de entidade foi encontrada no documento, mas não há referência por esse nome definido. Muitas vezes, isso é causado pelo erro de ortografia do nome de referência, não comercializado ou por deixar o ponto-e-vírgula à direita (;). A causa mais comum desse erro é o e comercial não codificado em URLs, conforme descrito pelo WDG em "Ampersands in URLs". Referências de entidade começam com um e comercial (&) e terminam com um ponto-e-vírgula (;). Se você quiser usar um e comercial literal no seu documento, você deve codificá-lo como "&" (mesmo dentro de URLs!). Tenha o cuidado de encerrar as referências da entidade com um ponto-e-vírgula ou a referência da sua entidade pode ser interpretada em conexão com o texto a seguir. Também tenha em mente que as referências de entidades nomeadas diferenciam maiúsculas de minúsculas; & Aelig; e æ são caracteres diferentes. Se esse erro aparecer em alguma marcação gerada pelo código de manipulação de sessão do PHP, este artigo tem explicações e soluções para o seu problema.

2
Nishant

Depende da probabilidade de um ponto e vírgula acabar perto do seu &, fazendo com que ele exiba algo bem diferente.

Por exemplo, ao lidar com a entrada de usuários (digamos, se você incluir o assunto fornecido pelo usuário de uma postagem do fórum em suas tags de título), nunca saberá onde eles podem colocar pontos-e-vírgulas aleatórios e poderá exibir aleatoriamente entidades estranhas. Então sempre escape nessa situação.

Para o seu próprio HTML estático, com certeza, você poderia ignorá-lo, mas é tão trivial incluir o escape adequado, que não há uma boa razão para evitá-lo.

1
Douglas

se & for usado em html então você deve escapar

Se & for usado em strings javascript, por exemplo um alert('This & that'); ou document.href você não precisa usá-lo.

Se você estiver usando document.write, deverá usá-lo, por exemplo, document.write(<p>this &amp; that</p>)

1
Alex

Se você está realmente falando sobre o texto estático

<title>Foo & Bar</title>

armazenado em algum arquivo no disco rígido e servido diretamente por um servidor, então sim: provavelmente não precisa ser escapado.

No entanto, como existe muito pouco conteúdo HTML hoje em dia que é completamente estático, adicionarei o seguinte aviso que pressupõe que o conteúdo HTML é gerado a partir de alguma outra origem (conteúdo do banco de dados, usuário entrada, resultado da chamada de serviço da web, resultado da API herdada, ...):

Se você não escapar de um simples &, é possível que você também não escape de &amp; ou &nbsp; ou <b> ou <script src="http://attacker.com/evil.js"> ou de qualquer outro texto inválido. Isso significa que, na melhor das hipóteses, você está exibindo seu conteúdo de forma incorreta e, mais provavelmente, é suspeito de ataques XSS .

Em outras palavras: quando você já está checando e escapando de outros casos mais problemáticos, então não há quase nenhuma razão para deixar o não-totalmente-quebrado-mas-ainda-um-peixe-independente autônomo e sem escape.

0
Joachim Sauer