#html #wordpress #utf-8 #w3c-validation #byte-order-mark
#HTML #wordpress #utf-8 #w3c-проверка #знак порядка байтов
Вопрос:
У меня есть блог (основанный на WordPress). И попробуйте проверить с помощью w3c validator одну из моих страниц. Первая ошибка:
Line 1, Column 1: Non-space characters found without seeing a doctype first. Expected <!DOCTYPE html>.
<!DOCTYPE html><!-- HTML 5 -->
Кроме того, панель отладки (http://www.my-debugbar.com/wiki/IETester/HomePage ) соглашаюсь и показываю два невидимых символа раньше <!
, когда я открываю ту же страницу на вкладке «Проверка HTML» внутри этого инструмента. НО!!
- Эта строка HTML-кода взята из файла header.php в моей теме WordPress.
- Я загружаю этот файл со своего хостера на свой локальный жесткий диск.
- Первая строка header.php это
<!DOCTYPE html><!-- HTML 5 -->
- Когда я открываю header.php в текстовом сообщении RJ (просто расширенный текстовый редактор) указано: текущая кодировка для header.php является UFT-8 без(!) спецификации.
- Когда я открываю header.php в HEX-Viewer я вижу, что байты 0 и 1 равны 3c, 21 — так это точно
<!
.
Итак, учитывая все обстоятельства, почему и откуда я беру эти «нечетные символы»?
Комментарии:
1. До прочтения пунктов 4 и 5 я думал, что ответ был довольно простым. Это интересно.
Ответ №1:
Я нашел корень проблемы. Общее правило таково:
Если какой-либо (абсолютно любой!) файл, который участвует в создании кода конечной HTML-страницы (той, которая будет отправлена клиенту), имеет кодировку с BOM — конечная HTML-страница БУДЕТ UTF-8-BOM. То есть: весь ваш сайт не должен содержать даже 1 файл со спецификацией.
В моем случае у меня всего 1,3 Тыс. файлов, составляющих мой сайт. Было загружено только 4 файла:
- wp-config.php (в корне сайта)
- jquery.query.js (в папке include)
- cyr-to-lat.php (в папке плагина)
- footer.php (в корневой папке темы)
И я был вынужден повторно сохранить все эти 4 файла как «UFT-8 без спецификации», чтобы избавиться от ошибки проверки «Символов, не содержащих пробелов». Когда я сделал это (повторно сохранил файлы) — ошибка исчезла.
Комментарии:
1. Спасибо. Помимо ошибки проверки, я получал огромное пустое пространство прямо над меню навигации моего сайта WordPress, что действительно заставляло меня бороться в течение нескольких дней, пытаясь определить, что было причиной проблемы с пробелом… Затем я изменил кодировку в Smultron.app для Mac и удалил параметр спецификации UTF-8, повторно загрузил файлы моей темы, и проблема была решена!!
2. Мне нравятся эти типы ошибок проверки
Кто-нибудь тестировал это решение с Notepad ? Будет очень сложно сохранять каждый новый файл в кодировке utf8-without-bom…