Безопасно ли убирать пробел между "содержимым" и "кодировкой"?
Я уже искал некоторое время, и мне не удалось найти никаких ссылок на то, безопасно ли / возможно ли удалить место здесь:
<meta http-equiv="Content-Type" content="text/html;это пространствоcharset=UTF-8" />
Я также пытался сжать сценарий "Агрессивная минимизация", но они, похоже, не удаляют его.
Я вижу, что они убрали место на этом примере веб-сайта. Но я больше не могу полагаться на такие сайты.
3 ответа
Спецификация заголовка Content-Type фактически не допускает пробелов вокруг точек с запятой, которые разделяют параметры:
http://www.ietf.org/rfc/rfc2045.txt
5.1. Синтаксис поля заголовка типа содержимого
В расширенной нотации BNF RFC 822 поле заголовка Content-Type
значение определяется следующим образом:
content:= "Content-Type" ":" type "/" subtype
* (параметр ";")
...
параметр:= атрибут "=" значение
Но кажется, что клиенты / серверы надежно обрабатывают пространства, которые могут быть добавлены, возможно, для того, чтобы сделать заголовки более читабельными. Вы можете безопасно опустить пространство.
Спецификация типов носителей, RFC 2045, не требует пробела. И при этом это не запрещает место; это более неявно, так как RFC 2045 ссылается на расширенный BNF, как определено в RFC 822, который поясняет это в пункте 3.4.2. БЕЛОЕ ПРОСТРАНСТВО:
"Примечание. В структурированных телах полей несколько символов ASCII линейного пространства (а именно HTAB и SPACE) обрабатываются как одиночные пробелы и могут свободно окружать любой символ. Во всех полях заголовка ТРЕБУЕТСЯ только то место, в котором требуется по крайней мере один символ LWSP, в начале строк продолжения в сложенном поле ".
Согласно черновикам HTML5, конкретный вид meta обсуждаемые теги могут быть записаны в следующей более компактной форме на том основании, что пользовательские агенты уже давно ее распознают:
<meta charset=UTF-8>
Если необходима сериализация XHTML, используйте
<meta charset="UTF-8" />
Это удобочитаемее и безопаснее (меньше ошибок при наборе текста вручную).
В этом нет никакого вреда, если есть точка с запятой ";" после text/html...
Похоже, в Exchange Web Server раньше была ошибка, которая требовала места, но браузерам в общем-то все равно.