Мені дійсно потрібно кодувати "&" як "& amp;"

Я використовую &символ " " з HTML5 та UTF-8 у своїх сайтах <title>. Google показує розмір амперсанда та штраф на своїх SERP, як і всі браузери в їх назвах.

http://validator.w3.org дає мені це:

& не запустив посилання на персонаж. (І, мабуть, слід було б уникнути як &.)

Мені справді потрібно робити &?

Мене не метушить, що мої сторінки перевіряються заради перевірки, але мені цікаво почути думку людей щодо цього, і якщо це важливо і чому.

Так. Так само, як сказано в помилці, атрибути в HTML - це #PCDATA, тобто вони розібрані. Це означає, що ви можете використовувати атрибути символів у атрибутах. Використання &саме по собі неправильно, і якщо не поблажливіші браузери, а той факт, що це HTML, а не XHTML, порушив би синтаксичний аналіз. Просто уникнути цього як &і все було б добре.

HTML5 дозволяє залишити його без нагляду, але лише тоді, коли наведені нижче дані не виглядають як дійсні посилання символів. Однак краще просто уникнути всіх екземплярів цього символу, ніж турбуватися про те, які з них мають бути, а які не повинні бути.

Пам'ятайте про це; якщо ви не ухиляєтесь від & to & amp ;, це досить погано для створених вами даних (там, де код може бути недійсним), ви також не можете уникнути розмежувачів тегів, що є величезною проблемою для поданих користувачем даних, що дуже добре може призвести до введення HTML та скриптів, крадіжок файлів cookie та інших подвигів.

Будь ласка, уникайте свого коду. Це вбереже вам багато клопоту в майбутньому.

Проверка вбік, залишається фактом, що кодування певних символів є важливим для документа HTML, щоб він міг правильно та безпечно відображатись як веб-сторінка.

Кодування, &як &за будь-яких обставин, для мене - це простіше правило, яким можна жити, зменшуючи ймовірність помилок і збоїв.

Порівняйте наступне: що простіше? що простіше підробити ?

Методика 1

1. Напишіть деякий вміст, який включає символи "амперсанд".
2. Зашифруйте їх усі.

Методика 2

(з зерном солі, будь ласка;))

1. Напишіть деякий вміст, який включає символи "амперсанд".
2. Проаналізуйте кожен окремий випадок. Визначте, чи:
   • Він ізольований і як такий однозначно амперсанд. напр. volt & amp
      > У такому випадку не переймайтеся кодуванням.
   • Він не є ізольованим, але ви вважаєте, що це, однак, однозначно, оскільки отримана сутність не існує і ніколи не існуватиме, оскільки список організацій ніколи не міг би розвиватися. напр. amp&volt
      > У цьому випадку не переймайтеся кодуванням.
   • Це не ізольовано, а неоднозначно. напр. volt&amp
      > Кодуйте його.

??

Правила HTML5 відрізняються від HTML4. Це не потрібно в HTML5 - якщо амперсанд не схожий на те, що він починає назву параметра. Наприклад, "& copy = 2" залишається проблемою, наприклад, оскільки & copy; є символом авторського права.

Однак мені здається, що важче працювати вирішити, чи не кодувати, залежно від наступного тексту. Тож найпростіший шлях - це, мабуть, кодування весь час.

Я думаю, що це перетворилося на більше питання про те, "чому дотримуватися специфікації, коли браузер не хвилює". Ось моя узагальнена відповідь:

Стандарти - це не «присутні» речі. Вони - річ "майбутнього". Якщо ми, як розробники, дотримуємося веб-стандартів, то, швидше за все, постачальники браузерів правильно застосовують ці стандарти, і ми переходимо ближче до цілком сумісної мережі, де CSS-хаки, виявлення функцій та виявлення браузера не потрібні. Там, де нам не потрібно розбиратись, чому наші макети розбиваються на конкретний веб-переглядач, або як їх обійти.

Зокрема, якщо HTML5 не вимагає використання & amp; у вашій конкретній ситуації, і ви використовуєте doctype HTML5 (а також очікуєте, що ваші користувачі використовуватимуть браузери, сумісні з HTML5), то немає підстав для цього.

Ну, якщо це з введення користувача, то абсолютно так, з очевидних причин. Подумайте, якщо цей веб-сайт цього не зробив: назва цього питання відобразиться, як мені справді потрібно кодувати "&" як "&"?

Якщо це просто щось на кшталт, echo '<title>Dolce & Gabbana</title>';то строго кажучи, не потрібно. Було б краще, але якщо ви цього не зробите, користувач не помітить різниці.

Не могли б ви показати нам, що titleє насправді? Коли я подаю

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

на http://validator.w3.org/ - явно просити його використовувати експериментальний режим HTML 5 - у нього немає скарг на &s ...

У HTML &позначає початок посилання, або посилання символів, або посилання на сутність . З цього моменту на аналізатор очікує або #позначення посилання символу, або ім'я сутності, що позначає посилання на сутність, за яким слідує a ;. Це нормальна поведінка.

Але якщо ім'я посилання або просто посилання відкриття &супроводжується пропуском або іншими роздільниками подобається ", ', <, >, &, закінчення ;і навіть посилання для подання рівнини &можна опустити:

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

Тільки в цих випадках закінчення ;або навіть сама посилання можуть бути опущені (принаймні, в HTML 4). Я думаю, що HTML 5 вимагає закінчення ;.

Але специфікація рекомендує завжди використовувати такі посилання, як посилання символів &або посилання на сутність, &щоб уникнути плутанини:

Автори повинні використовувати " &" (ASCII десятковий 38) замість " &", щоб уникнути плутанини з початком посилання символів (відкритий роздільник обмеження сутності). Автори також повинні використовувати " &" значення значень атрибутів, оскільки посилання символів дозволені в значеннях атрибутів CDATA.

Якщо користувач передасть його вам, або він з’явиться в URL-адресі, вам потрібно уникнути цього.

Якщо він відображається в статичному тексті на сторінці? Усі браузери отримають це право в будь-якому випадку, ви не дуже турбуєтесь про це, оскільки він буде працювати.

Оновлення (березень 2020 р.): Валідатор W3C більше не скаржиться на уникнення URL-адрес.

Я перевіряв, чому потрібно уникати URL-адреси зображення, тому спробував це в https://validator.w3.org . Пояснення досить приємне. Це підкреслює, що навіть URL-адреси потрібно уникати. [PS: Я вважаю, що він не зміниться, коли його буде використано з моменту потреби URL-адреси &. Хтось може уточнити?]

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

У документі знайдено посилання на суб’єкт господарювання, але посилання на цю назву не визначено. Часто це спричинено неправильним написанням опорного імені, некодованими амперсандами або відхиленням крапки з комою (;). Найпоширенішою причиною цієї помилки є некодовані розширення в URL-адресах, як описано WDG у розділі "Амперсанд в URL-адресах". Посилання на об'єкти починаються з символу "" (")" і & закінчуються крапкою з комою (;). Якщо ви хочете використовувати в своєму документі буквальну амперсанд, ви повинні кодувати це як "&" (навіть усередині URL-адрес!). Будьте обережні, щоб закінчити посилання юридичних осіб крапкою з комою або посилання вашої сутності може бути інтерпретоване у зв'язку з наступним текстом. Також майте на увазі, що названі посилання суб’єктів залежать від регістру; & Aelig; і æ - різні символи.

Так, ви можете спробувати подати дійсний код, якщо це можливо.

Більшість браузерів мовчки виправлять цю помилку, але існує проблема із посиланням на обробку помилок у веб-переглядачах. Немає стандартів поводження з невірним кодом, тому кожен постачальник браузера повинен намагатися розібратися, що робити з кожною помилкою, і результати можуть відрізнятися.

Деякі приклади, коли веб-переглядачі, ймовірно, реагують по-різному - це якщо ви помістите елементи всередину таблиці, але поза клітинками таблиці, або якщо ви вкладете посилання всередині одного.

Для вашого конкретного прикладу це, ймовірно, не спричинить жодних проблем, але виправлення помилок у веб-переглядачі може, наприклад, призвести до переходу браузера з режиму, сумісного зі стандартами, у режим примх, що може змусити ваш макет повністю зруйнуватися.

Отже, вам слід виправити подібні помилки в коді, якщо не що-небудь інше, щоб не було списку помилок у валідаторі коротким, щоб ви могли помітити більш серйозні проблеми.

Пару років тому ми отримали звіт про те, що один із наших веб-додатків не відображався належним чином у Firefox. Виявилося, що на сторінці містився тег, який виглядав так

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

Зустрічаючись з повторним атрибутом стилю, IE поєднує обидва стилі, тоді як Firefox використовує лише один з них, отже, і різну поведінку. Я змінив тег на

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

і, звичайно, досить, вона виправила проблему! Мораль історії полягає в тому, що браузери мають більш послідовну обробку дійсного HTML, ніж недійсного HTML. Отже, виправте вже свою прокляту розмітку! (Або використовуйте HTML Tidy, щоб виправити це.)

якщо &він використовується в HTML, то вам слід уникати цього

Якщо &використовується в рядках javascript, наприклад, alert('This & that');або document.href, вам не потрібно використовувати його.

Якщо ви використовуєте document.write, тоді ви повинні використовувати його, наприклад document.write(<p>this &amp; that</p>)

Це залежить від ймовірності того, що крапка з комою закінчиться біля вашого &, що призведе до того, що він відображатиме щось зовсім інше.

Наприклад, працюючи з інформацією від користувачів (скажімо, якщо ви включите в теги заголовка надану користувачем тему повідомлення на форумі), ви ніколи не знаєте, де вони можуть розміщувати випадкові крапки з комою, і це може випадково відображати дивні сутності. Тому завжди біжіть у цій ситуації.

Для вашого власного статичного html, звичайно, ви можете його пропустити, але це настільки банально, щоб включити правильне втечу, що немає жодних вагомих причин уникнути цього.

Якщо ви справді говорите про статичний текст

<title>Foo & Bar</title>

зберігається в якомусь файлі на жорсткому диску і подається безпосередньо сервером, тоді так: його, ймовірно, не потрібно уникати.

Однак, оскільки на сьогоднішній день дуже мало вмісту HTML, що є повністю статичним, я додам наступну відмову, яка передбачає, що вміст HTML генерується з якогось іншого джерела (вміст бази даних, введення користувача, результат виклику веб-служби, результат застарілого API,. ..):

Якщо ви не уникнути простий &, то швидше за все , ви також не уникнути &або  або <b>або <script src="http://attacker.com/evil.js">будь-якої іншої невірний текст. Це означає, що ви в кращому випадку показуєте вміст неправильно і, швидше за все, піддаєтеся нападу XSS .

Іншими словами: коли ви вже перевіряєте та ухиляєтесь від інших більш проблемних випадків, то майже немає причин залишати не зовсім розбитий, але все ще дещо рибний автономний - і без нагляду.

не впевнений, чи корисно це кому-небудь ... Я боровся з цим деякий час ... ось славний вираз, який ви можете використати, щоб виправити всі ваші посилання, JavaScript, вміст. Мені довелося зіткнутися з тоною застарілого вмісту, який ніхто не хотів виправити.

Додайте це до перегляду Render на своїй головній сторінці або елементі управління:

Будь ласка, не спалахуйте мене за те, що поставити це в неправильному місці:

// 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);

Посилання має досить хороший приклад того , коли і чому ви , можливо , доведеться піти &в&

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

Цікаво, що мені довелося уникнути персонажа, щоб правильно його зобразити у своїй відповіді. Якби я використовував вбудований параметр зразка коду (на панелі відповідей), я можу просто ввести &і він виглядає як слід. Але якби я вручну використовував <code></code>елемент, то мені доведеться бігти, щоб правильно його представити :)