|
|
Charset. Ставить или нет?
Сколько существует русскоязычный интернет, столько ведутся непрерывные
баталии по поводу установки тэга charset в код HTML страницы. Charset,
наверное, один из самых несчастных HTML тэгов. И коллизии он вызывает,
и неоднозначности в раскодировке страницы появляются, и серверу
перекодировать страницы под клиента мешает. В общем договорились до
того, что большинство "авторитетов" веб издательства считают, что тэг
Charset вреден, и использование его внутри страниц черевато
неприятностями.
Может быть оно и так, но ведь тэг charset
был придуман не просто так, а чтобы броузер, или еще какой HTTP клиент
смог безо всяких ухищрений разобраться в какой кодировке и на каком
языке написано содержимое страницы. Если Вы отдаете страницу в
кодировке 1251, то почему об этом не сказать явно, при помощи тэга
charset? Мне возразят, что есть вероятность, что клиент получает
страницу через перекодирующий прокси сервер, который может изменять
кодировку документа, к примеру с 1251 на кои8. На что я отвечу, что
во-первых доля клиентов, использующих для доступа в интернет
перекодирующие прокси сервера, исчезающе мала, во-вторых, правильно
настроенный перекодирующий http прокси сервер просто обязан понимать
тэги charset, и если такового не происходит, то это проблемы владельца
прокси сервера.
И не нужно бояться, что тэг charset не
поймет броузер, или еще какой http клиент. Эпоха netscape 2.0 прошла
много лет назад. Сейчас все броузеры и поисковые роботы понимают тэги
charset.
Единственная сложность. В некоторых случаях Вы не
можете гарантированно определить в какой кодировке отдается документ
клиенту. В этом случае Charset может сослужить плохую службу. Случаи
такие наступают, как Вы , наверное, догадались, при использовании
русифицированного программного обеспечения. В частности при установке
apache/RUS. Не знаю, какими соображениями руководствовались
разработчики локальной версии, но алгоритм автоматической перекодировки
HTML страниц не поддается никакому логическому объяснению. Во-первых
apache/RUS полностью игнорирует тэг charset, перекодированная страница
уходит клиенту со старым тэгом. Во-вторых ,исходную кодировку документа
apache/RUS определяет не по содержимому страницы, а по настройкам своих
конфигов.
Впрочем это еще не так страшно. Основная беда в
том, что отдаваемую кодировку документа предсказать практически
невозможно. Для Microsoft Explorer документы отдаются преимущественно в
кодировке win 1251. Для Netscape Navigator и Communicator, как
придется, в зависимости от версии и платформы. Особенно это "радует",
если вспомнить, что Netscape Communicator не умеет определять кодировку
документа без тэга charset и показывает документы в кодировке
предыдущей просмотренной страницы. Что же касается прочих Mozzila
совместимых и не очень, клиентов, то они получают в основном
принудительные кои8 HTML документы. Но опять-таки гарантии нету
никакой. В этом случае можно посоветовать три варианта.
Первый, самый простой. Выкинуть тэги charset из своих страниц,
перекодировать страницы в исходную кодировку для apache/RUS и
надеяться, на его интеллект.
Второй. Отключить
автоматическое преобразование кодировок документов при помощи директивы
CharsetTurnOff On в файле .htaccess, и занимайтесь самостоятельной
перекодировкой документа в зависимости от версии http клиента. Для всех
Mozzila совместимых клиентов отдавайте страницы в кодировке 1251 а для
остальных кои8, с обязательным указанием тэга charset.
Третий. Самый толковый, но возможный только в том случае, если у вас
есть полный доступ к настройкам вашего http сервера apache.
Итак:
Перекодируйте все документы на вашем http сервере в кодировку win1251.
Замените следующий тэг на тэг , это укажет, что ваш документ на русском языке и облегчит жизнь поисковым роботам.
|
| Категория: HTML | Добавил: Djakob (16.10.2008)
|
| Просмотров: 354
| Рейтинг: 0.0/0 |
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
|
Сейчас на сайте: 1 Гостей: 1 Пользователей: 0
|
& design by Sapon&manysoft-net.ru