Использует для '"' объект в HTML
Я пересматриваю несколько файлов XHTML, созданных другой стороной. В рамках этой работы я делаю небольшое редактирование через Linq to XML.
Я только что заметил, что некоторые исходные исходные файлы XHTML содержат "
объект HTML в текстовых узлах этих файлов. Например:
<p>Greeting: "Hello, World!"</p>
И что при восстановлении текста XHTML с помощью XElement.ToString() объекты "
заменяются на простые двойные кавычки:
<p>Greeting: "Hello, World!"</p>
Вопрос:. Может ли кто-нибудь сказать мне, чем могла быть мотивация для оригинального автора использовать объекты "
вместо простых двойных кавычек? Являются ли эти организации той целью, которую я не совсем понимаю? Или, действительно ли они были лишними, поскольку я подозреваю?
Я понимаю, что "
потребуется в определенных контекстах, например, когда необходимо поместить двойную кавычку в атрибут HTML. Например:
<a href="/images/hello_world.jpg" alt="Greeting: "Hello, World!"">
Greeting</a>
Ответы
Ответ 1
Невозможно и не нужно знать мотивацию использования "
в содержании элементов, но возможные мотивы включают: непонимание правил HTML; использование программного обеспечения, которое генерирует такой код (возможно, потому, что его автор считал его "более безопасным" ); и непонимание значения "
: многие люди, похоже, думают, что он производит "умные цитаты" (они, по-видимому, никогда не смотрели на фактические результаты).
Во всяком случае, никогда не нужно использовать "
в содержимом элемента в HTML (XHTML или любую другую версию HTML). В любой спецификации HTML нет ничего, что бы присвоить какой-либо особый смысл простому символу "там".
Как говорится в этом вопросе, он играет свою роль в значениях атрибутов, но даже в них проще просто использовать одинарные кавычки как разделители, если значение содержит двойную кавычку, например. alt='Greeting: "Hello, World!"'
или, если вам разрешено исправлять ошибки в текстах на естественном языке, использовать правильные кавычки, например. alt="Greeting: "Hello, World!""
Ответ 2
Причина № 1
Была точка, где багги/ленивые реализации визуализаторов HTML/XHTML были более распространены, чем те, которые получили это право. Много лет назад я регулярно сталкивался с проблемами рендеринга в основных браузерах в результате использования символов некодированного кавычки в регулярном текстовом содержимом документов HTML/XHTML. Хотя спецификация HTML никогда не запрещала использовать эти символы в текстовом контенте, в какой-то степени стандартная практика кодировала их, так что браузеры, не совместимые со спецификациями, и другие процессоры будут обрабатывать их более изящно. В результате многие "старожилы" все еще могут сделать это рефлексивно. Это неверно, хотя теперь это, вероятно, не нужно, если вы не нацеливаете некоторые очень архаичные платформы.
Причина № 2
Когда HTML-контент генерируется динамически, например, путем заполнения шаблона HTML с помощью простых строковых значений из базы данных, необходимо кодировать каждое значение перед его встраиванием в сгенерированный контент. Некоторые общие серверные языки предоставляли для этой цели одну функцию, которая просто кодировала все символы, которые могут быть недопустимыми в некотором контексте в HTML-документе. Примечательно, что одним из таких примеров является PHP htmlspecialchars()
. Хотя есть необязательные аргументы для htmlspecialchars()
, которые заставят его игнорировать кавычки, эти аргументы (и редко) использовались авторами базовых систем, управляемых шаблонами. В результате все "специальные символы" кодируются везде, где они встречаются в сгенерированном HTML, без учета контекста, в котором они происходят. Опять же, это неверно, это просто лишнее.
Ответ 3
По моему опыту это может быть результатом автоматического генерации с помощью строковых инструментов, где автор не понимал правил HTML.
Когда некоторые разработчики генерируют HTML без использования специальных XML-ориентированных инструментов, они могут попытаться убедиться, что полученный HTML-код действителен, принимая подход, при котором все должно быть экранировано.
Ссылаясь на ваш пример, причина, по которой каждое появление "
представляется "
, может быть связано с использованием этого подхода, вы можете безопасно использовать такие "специальные" символы в обоих атрибутах и значениях.
Другая мотивация, которую я видел, - это то, где люди верят: "Мы должны явно показать, что наши символы не являются частью синтаксиса". Принимая во внимание, что действительный HTML может быть создан с помощью правильных инструментов манипуляции строками, см. Предыдущий параграф снова.
Ниже приведен некоторый псевдокод на основе С#, хотя предпочтительнее использовать действительные методы и инструменты:
public class HtmlAndXmlWriter
{
private string Escape(string badString)
{
return badString.Replace("&", "&").Replace("\"", """).Replace("'", "'").Replace(">", ">").Replace("<", "<");
}
public string GetHtmlFromOutObject(Object obj)
{
return "<div class='type_" + Escape(obj.Type) + "'>" + Escape(obj.Value) + "</div>";
}
}
Очень часто встречаются такие подходы к созданию HTML.
Ответ 4
Как указывалось в других ответах, это скорее всего сгенерировано каким-то инструментом.
Но если бы я был оригинальным автором файла, я бы ответил: Консистенция.
Если мне не разрешено вводить двойные кавычки в мои атрибуты, зачем вкладывать их в содержимое элемента? Почему эти спецификации всегда имеют эти исключительные случаи.
Если бы мне пришлось написать спецификацию HTML, я бы сказал All double quotes need to be encoded
. Готово.
Сегодня это похоже на In attribute values we need to encode double quotes, except when the attribute value itself is defined by single quotes. In the content of elements, double quotes can be, but are not required to be, encoded.
(И я, конечно, забываю о некоторых случаях здесь).
Двойные кавычки являются ключевым словом спецификации, кодируют их.
Мало/больше, чем ключевое слово spec, закодируйте их. и т.д..