Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Сабж, собственно говоря — должны ли HTML-страницы в кодировке UTF-8 содержать в начале так называемый BOM или для браузера достаточно обычного
Здравствуйте, anonymous, Вы писали:
A>BOM не нужен.
ОК, спасибо. А если с другой стороны зайти (для полного удовлетворения моего любопытства) — наличие в HTML-странице BOM-а может как-то повлиять на поведение барузера? противоречит ли это наличие каким-либо правилам/стандартам?
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]
Здравствуйте, SchweinDeBurg, Вы писали:
A>>BOM не нужен. SDB>ОК, спасибо. А если с другой стороны зайти (для полного удовлетворения моего любопытства) — наличие в HTML-странице BOM-а может как-то повлиять на поведение барузера? противоречит ли это наличие каким-либо правилам/стандартам?
Поскольку понятие порядка следования байт не применимо к UTF-8, то раньше для него не предполагалось использовать BOM, да и сейчас не рекомендуется. Поэтому очень многие утилиты могут неверно интерпретировать текст с BOM. Резюме: BOM с UTF-8 лучше не использовать.
Здравствуйте, anonymous, Вы писали:
A>Поскольку понятие порядка следования байт не применимо к UTF-8, то раньше для него не предполагалось использовать BOM, да и сейчас не рекомендуется. Поэтому очень многие утилиты могут неверно интерпретировать текст с BOM. Резюме: BOM с UTF-8 лучше не использовать.
Теперь все предельно ясно, спасибо еще раз!
P.S.
Последний вопрос был продиктован еще и опасением нарваться на какой-нибудь текстовый редактор, который без BOM-а не сможет правильно понять "исходник" страницы. WeBuilder и Edit+, которыми я пользуюсь, таким не страдают, но ведь "от сумы да от тюрьмы..."
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Последний вопрос был продиктован еще и опасением нарваться на какой-нибудь текстовый редактор, который без BOM-а не сможет правильно понять "исходник" страницы. WeBuilder и Edit+, которыми я пользуюсь, таким не страдают, но ведь "от сумы да от тюрьмы..."
Боюсь любой, если у него кодировка по умолчанию отлична от UTF неправильно определят без BOM. Покрайней мере Komodo Edit и Notepad++ открывают файлы без BOM в кодировке по умолчанию, а с BOM в UTF-8. Точно такое же поведение задокументировано как стандарное для .Net FrameWork. Но в редактор попадеает временный файл сделанный браузером, а вот как браузер делает: как получил с сервера или допишет своё это вопрос.
... << My edition based on RSDN@Home 1.2.0 alpha 4 rev. 1476 >>
В задаче спрашивается:
Сколько вытечет портвейна из открытого бассейна?
Здравствуйте, stele, Вы писали:
S>Боюсь любой, если у него кодировка по умолчанию отлична от UTF неправильно определят без BOM. Покрайней мере Komodo Edit и Notepad++ открывают файлы без BOM в кодировке по умолчанию, а с BOM в UTF-8.
Ну, не знаю... только что проверил WeBuilder 2010, в котором кодировкой по умолчанию указана ANSI — он корректно открыл файл в UTF-8, содержащий русккий текст, при отсутствующем BOM-e. В Edit+ я такой настройки вообще не нашел и он тоже открывает корректно. Имеются ввиду локальные файлы.
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]
Если этот html будет раздаваться с http-сервера, такая meta не только не нужна, но и вредна, поскольку создаёт видимость того, что на сервер можно положить файлы в разных кодировках и указать кодировку внутри каждого файла. На самом же деле http-клиент (браузер) обязан в первую очередь смотреть на реальный заголовок Content-Type, передаваемый браузером. А он в большинстве случаев жёстко настраивается по расширению в конфигурационном файле сервера.
Здравствуйте, Centaur, Вы писали:
C>В XML 1.0 BOM требуется для UTF-16 и разрешается для UTF-8. C>В HTML 4.01 BOM рекомендуется для UTF-16 и не регламентируется для UTF-8.
Исчерпывающе, спасибо.
C>Если этот html будет раздаваться с http-сервера, такая meta не только не нужна, но и вредна, поскольку создаёт видимость того, что на сервер можно положить файлы в разных кодировках и указать кодировку внутри каждого файла. На самом же деле http-клиент (браузер) обязан в первую очередь смотреть на реальный заголовок Content-Type, передаваемый браузером. А он в большинстве случаев жёстко настраивается по расширению в конфигурационном файле сервера.
Интересно, не знал. Но выделенное, как я понимаю, следует читать "передаваемый сервером"?
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]
Здравствуйте, SchweinDeBurg, Вы писали:
C>>Если этот html будет раздаваться с http-сервера, такая meta не только не нужна, но и вредна, поскольку создаёт видимость того, что на сервер можно положить файлы в разных кодировках и указать кодировку внутри каждого файла. На самом же деле http-клиент (браузер) обязан в первую очередь смотреть на реальный заголовок Content-Type, передаваемый браузером. А он в большинстве случаев жёстко настраивается по расширению в конфигурационном файле сервера.
SDB>Интересно, не знал. Но выделенное, как я понимаю, следует читать "передаваемый сервером"?
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Доброго времени суток, коллеги!
SDB>Сабж, собственно говоря — должны ли HTML-страницы в кодировке UTF-8 содержать в начале так называемый BOM или для браузера достаточно обычного
SDB>
Metadata received in an encapsulating container MUST be considered authoritative and used in preference to metadata found by inspection of the data, declared by embedded metadata, or provided by external reference.
То есть браузер сначала смотрит на ярлык, а потом на содержимое.
В частности, чтобы определить, в какой кодировке показывать страницу, браузер:
1. сперва смотрит на ее HTTP хидер (Content-Type: text/html; charset=...)
2. если нет HTTP хидера, смотрит на HTML хидер (<meta http-equiv="Content-Type" content="text/html; charset=..."/>)
3. если нет HTML хидера, браузер пытается угадать кодировку через анализ контента. Вот тут BOM может сыграть свою роль.
Вот тут можно почитать как это делает Mozilla (Firefox). На основе Mozill-овского детектора кстати сделан Python-ский модуль chardet, который используется во многих HTML scraper-ах вроде BeautifulSoup.
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Доброго времени суток, коллеги!
SDB>Сабж, собственно говоря — должны ли HTML-страницы в кодировке UTF-8 содержать в начале так называемый BOM или для браузера достаточно обычного
SDB>
В моей практике был случай, когда HTML-страница, содержащая BOM, разваливалась в IE7, т.е. отображалась так, как будто не подтягивает css-файл. В остальных браузерах было все ОК. Потратив кучу времени на выяснение того, что виноват в этом BOM, я твердо решил, что он в файлах не нужен, и поудалял его из всех .php, .tpl, .css, .js файлов всех проектов, где он был.
Через некоторое время возникла другая проблема. На сайте одного из заказчиков в админке для редактирования контента используется FCKEditor. Выянилось, что при сохранении редактор некоторые символы кириллицы конвертирует в html-entities, что пагубно сказывается на SEO-позиции сайта. Список символов:
в — в
Е — Е
Г — Г
В — В
П — П
О — О
Л — Л
Ж — Ж
ё – ё
Вдобавок, если переключить язык интерфейса редактора на русский, то интерфейс отображается кракозябликами. Понятно, что-то не ОК с кодировкой. Как выяснилось, статика на сервере, где хостится сайт, отдается nginx-ом, и кодировка в заголовках ответов не установлена. Добавление BOM-а в js-файлы FCKEditor-а решило обе проблемы: редактор правильно отображает русский интерфейс и перестал конвертировать русские буквы.
Здравствуйте, Каспер, Вы писали:
[cut]
К>Вдобавок, если переключить язык интерфейса редактора на русский, то интерфейс отображается кракозябликами. Понятно, что-то не ОК с кодировкой. Как выяснилось, статика на сервере, где хостится сайт, отдается nginx-ом, и кодировка в заголовках ответов не установлена. Добавление BOM-а в js-файлы FCKEditor-а решило обе проблемы: редактор правильно отображает русский интерфейс и перестал конвертировать русские буквы.
Я, конечно, извиняюсь, но не логичнее было исправить конфигурацию сервера? Или речь про не совсем удачный хостинг?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Каспер, Вы писали: К>[cut]
К>>Вдобавок, если переключить язык интерфейса редактора на русский, то интерфейс отображается кракозябликами. Понятно, что-то не ОК с кодировкой. Как выяснилось, статика на сервере, где хостится сайт, отдается nginx-ом, и кодировка в заголовках ответов не установлена. Добавление BOM-а в js-файлы FCKEditor-а решило обе проблемы: редактор правильно отображает русский интерфейс и перестал конвертировать русские буквы.
К>Я, конечно, извиняюсь, но не логичнее было исправить конфигурацию сервера? Или речь про не совсем удачный хостинг?
Да, речь именно про не совсем удачный хостинг. Более того, позже проблема наблюдалась у других заказчиков еще на двух хостингах.
