Http кодировка. Кодировка HTML-страницы

Надеюсь я вас убедил и вы будете использовать Юникод (кстати «utf-8» и «Юникод» - это синонимы или, если быть более точным, utf-8 - это одна из кодировок семейства Юникод, которая снискала популярность в среде веб-разработчиков).

Теперь пристально посмотрим на инструменты перекодирования файлов, которые я рекомендую вам использовать, уважаемый читатель.

Инструменты для работы с кодировками HTML файлов

Собственно, их всего три:

• PSPad . Бесплатный текстовый редактор, мой любимый.
• . Еще один хороший текстовый редактор и тоже бесплатный.
• Dreamweaver. Ну с Dreamweaver-ом вы с вами знакомы из моих .

Загружаем какой-то HTML-файл в PSPad. И как же нам понять, что за кодировка у загруженного подопытного? Очень просто в строке состояния (внизу) все четко написано.

Кодировка открытого HTML-файла windows-1251

А теперь, создавая новый HTML-документ, позаботимся о его кодировке.

Идем в меню моего любимого PSPad-а . Нас интересует пункт Формат . В нем-то мы и поставим галку напротив кодировки utf-8.

А так кодировка будующего файла - windows-1251

Теперь о том как изменить кодировку файла HTML . Да оказывается очень просто:

Нужно кликнуть по требуемой кодировке в пункте меню Формат и кодировка сменится. После этого сохраняйте файл, он перекодирован, дело сделано.

Что касается Notepad++ все очень похоже на вышеописанную ситуацию. Только для работы с кодировками нужно использовать пункт меню Кодировки.

Вся разница заключается в том, что в случае Notepad++ появляются, специально разработанные для преобразования кодировок, пункты меню Преобразовать.. . (лишние на мой взгляд, в PSPad все проще и поэтому я им пользуюсь). Соответственно, именно по ним и нужно кликать при желании поменять кодировки у нашего HTML-файла.

Кроме всего прочего, при сохранении в utf-8 у нас есть выбор: без BOM или с BOM . Нам, как веб-мастерам, нужно использовать кодировку UTF-8 (без BOM) .

Вот что нам ответит Википедия на вопрос «что такое BOM »

Для определения формата представления Юникода в текстовом файле используется приём, по которому в начале текста записывается символ U+FEFF (неразрывный пробел с нулевой шириной), также именуемый меткой порядка байтов (англ. Byte Order Mark, BOM). Этот способ позволяет различать UTF-16LE и UTF-16BE, поскольку символа U+FFFE не существует. Также он иногда применяется для обозначения формата UTF-8, хотя к этому формату и неприменимо понятие порядка байтов.

Если прочитать приведенный текст 10 раз, почесать затылок, то становится понятно: для utf-8 BOM нам НЕ нужен . Кроме того, если сохранить файл с php-скриптом в кодировку utf-8 с BOM , то он не будет работать, потому что обработчик не поймет, что это за ерунда такая написана в начале файла-скрипта (я имею ввиду тот самый неразрывный пробел с нулевой шириной).

Так-так, осталось пристально взглянуть на Dreamweaver .

Создавая новый файл, обращайте внимание на то, в какой кодировке он будет создан. Для этого в окне создания нового документа File → New (Ctrl+N) воспользуйтесь кнопкой Preferences ...

И посмотрите, что задано в качестве кодировки по умолчанию:

Кодировка создаваемого HTML-файла по умолчанию в Dreamweaver

Перекодировать открытый HTML-файл в Dreamweaver можно в диалоге Page Properties, который запускается из меню Modify → Page Properties (Ctrl + J).

Выбирайте требуемую кодировку, нажимайте ОК и все, задача по перекодированию выполнена (а вот BOM все так же ненужен, не ставьте галку).

Определение кодировки браузерами

Итак, наш HTML-файл сохранен в выбранную нами кодировку. Теперь давайте разберемся с вопросом: каким образом браузер узнает о применяемой в данном HTML-файле кодировке?

Здесь есть три варианта:

1. Мы сами сообщаем браузеру о том, какая кодировка установлена для данного HTML файла. Делается это посредством META-тега

В приведенном примере браузеру дается указание, что загруженный HTML-файл сохранен в кодировке utf-8 .

Если HTML-файл сохранен в кодировку windows-1251, то:

Кстати, при перекодировке файлов не забывайте изменять директивы в META-теге на актуальные. Dreamweaver, при изменении кодировки, делает это автоматически, а в других текстовых редакторах вам нужно самим ставить в соответствие примененную кодировку и директиву META-тега.

Полный HTML выглядит следующим образом (привожу его для понимания вопроса «в каком месте указывается META-тег с директивой кодировки» внимание на 4-ю строку):

Ну и т.д.

2. При помощи файла.htaccess. Иногда сервер насильно передает заголовки для загружаемых HTML-файлов и сообщает браузеру кодировку по умолчанию. В этом случае браузер не обращает внимания на директивы в META-теге, а отображает HTML-файл в той кодировки, которую сообщил сервер. Чтобы файл загружалсяв той кодировке, которая нужна вам (часто хостинг насильно указывает кодировку windows-1251), в корне хостинг-директории создается файл с именем «.htaccess».

Файл этот предназначен для дополнительной конфигурации сервера. Действие.htaccess-директив распространяется на все файлы и подкаталоги, которые находятся в том каталоге, куда вы сохранили файл.htaccess.

Создать этот файл можно, например, в Total Commander-е, нажав горячее сочетание клавиш Shift+F4 и указав имя создаваемому файлу .htaccess . Далее в текстовом редакторе указываются директивы дополнительных настроек кодировки по умолчанию.

Для HTML-файлов в кодировке utf-8 в.htaccess нужно написать одну строку:

AddDefaultCharset UTF-8

Для HTML-файлов в кодировке Windows-1251 :

AddDefaultCharset Windows-1251

Если ваш хостинг хитро-мудрый и не обращает внимания на эти директивы, то можно попробовать:

Charsetdisable on AddDefaultCharset Off

Если и это не дало результата, то просто спросите у своего хостера, чего вам делать, чтобы отключить кодировку по умолчанию:). Все это зависит от конкретных настроек сервера у хостинг-провайдера.

3. PHP-инструкция, указывающая кодировку по умолчанию. В файле, который нужно отобразить в желаемой кодировке, не смотря на настройки сервера хостинг-провайдера, в самом начале указывается директива с php-кодом:

Этот php-код отправит заголовок сервера с указанием кодировки по умолчанию для браузера. В приведенном примере, для отображения страницы, будет применяться кодировка utf-8.

Против такого лома, обычно, приемов в настройках сервера хостинг-провайдера не остается.

Хочу заметить, что для обработки php-инструкций сервером, html-файл должен иметь расширение .php (например index.php).

Есть еще вопросы по кодировкам? Пишите в комментарии. Нужно решить эти проблемы раз и на всегда 🙂

Начальные данные

1. Возьмём в качестве примера наш сайт: www.vashmaster.ru
2. Все тексты сайта написаны и размещены на сайте в кодировке "windows-1251" и об этом браузеру не сообщается
3. Сервер хостинга автоматически по умолчанию отправляет следующий заголовок:
   Content-Type: text/html; charset=utf-8

При подобном несовпадении в реальной кодировке сайта и информации о кодировке в заголовке, отправляемом сервером, возникнут проблемы отображения страниц сайта в браузере посетителей.

Правильная кодировка - это очень важно!

Попробуем объяснить почему.

При описанных выше настройках, браузер пользователя не сможет автоматически определить в какой же кодировке написаны тексты на просматриваемом сайте. И скорее всего будет отображать страницы в нечитаемых "кракозябрах". Если вы столкнулись с подобным "недопониманием" между браузером и вашим сайтом, то в срочном порядке необходимо принять соответствующие меры. Иначе, это с большой вероятностью приведёт к череде серьёзных проблем.

Во-первых , в подобных условиях и настройках сайта, посетителям придётся постоянно в ручную (методом подбора) указывать браузеру кодировку для отображения сайта. Для этого потребуется сделать несколько лишних кликов мышкой. Но согласитесь, не каждому понравится делать лишних 2-3 клика мышкой, чтобы просто увидеть информацию на странице в читабельном виде . Тем более, что очень многие даже и не знают не только как сменить кодировку отображения в настройках браузера, но и что такое кодировка вообще! Большинство посетителей могут решить что сайт заброшен владельцем или кем-нибудь взломан, и постараются на него больше не возвращаться.

Во-вторых , при неоднозначном определении кодировки страниц сайта, поисковые системы могут не правильно индексировать текстовое содержимое сайта . Что в свою очередь несёт серьёзные проблемы с трафиком пользователей с поисковых систем. Конечно, некоторые поисковые системы могут пытаться по содержимому страниц как-то определить их правильную кодировку, но намного легче от этого не становится. Как правило, проблема всё равно остаётся.

Надеюсь, вы осознали, что проблемы с кодировкой могут стать очень серьёзной преградой в функционировании сайта, в его развитии и привлечении на него постоянных посетителей.

Для того, чтобы подобных проблем с кодировкой не возникало, нужно сделать соответствующие настройка как на сервере хостинга, так и на страницах сайта.

Настройки сайта должны быть такими, чтобы любой браузер или любой робот поисковой системы могли ОДНОЗНАЧНО определить в какой кодировке передаётся информация с сайта!

Решение проблемы с кодировкой сайта

Мы уже заметили, что все тексты на нашем сайте написаны и передаются в браузер посетителю сайта в кодировке "windows-1251". Что же сделать, дабы сервер, на котором размещён наш сайт, передавал браузеру в заголовке правильную информацию о кодировке? Давайте действовать по порядку...

1. Чтобы не зависеть от настроек сервера , на всех страницах сайта прямо в коде HTML нужно, используя мета-тег, явно прописать следующую директиву:

Разместить её необходимо на всех страницах, желательно, сразу же после открывающегося тега . Это позволит браузеру автоматически в момент загрузки и интерпретации страницы выбрать правильную кодировку отображения в соответствии с полученной директивой! Одной этой директивы должно быть достаточно для решения нашей проблемы. Но так задумывалось в теории. А на практике, этой директивы не всегда достаточно. В редких случаях, но бывает так, что браузер в качестве кодировки для отображения страницы выбирает не ту, что указана в директиве на самой странице, а ту, что была передана в заголовке от сервера! И если указанная в двух местах информация о кодировке не совпадает, то проблема может остаться.

2. Чтобы сервер отдавал в своём ответе правильную информацию о кодировке , необходимо в корне своего сайта создать файл .htaccess и прописать в нём директиву:

AddDefaultCharset windows-1251

Тогда сервер продолжит по умолчанию отсылать заголовок о кодировке, но название кодировки будет совпадать с действующей на самом сайте. Ни каких несовпадений в названиях уже не будет.

Если файл .htaccess уже существует на вашем сервере, то просто добавьте указанную директиву, например, в самом начале. И ни в коем случае не удаляйте без надобности уже существующую в нём информацию!

Вот и всё решение проблемы. Согласитесь, всё это не так сложно?! Зато очень полезно для профилактики всевозможных проблем с пресловутой кодировкой.

Выполнив последовательно две перечисленные выше рекомендации, браузеры уже точно не смогут ошибиться в автоматическом выборе правильной кодировки отображения информации на вашем сайте. Всё-таки мы указали однозначно, правильно и даже в двух разных директивах информацию о кодировке!

Особые ситуации

Ситуация первая

Создатели сайтов, а чаще даже сами заказчики начинают самовольно и необдуманно вносить определённые доработки на сайт, размещать тексты так как им вздумается ну и т. д. Вплоть до того, что в результате на сайте могут оказаться разделы с информацией в разных кодировках . Не можем сказать, что это правильный подход, но будем отталкивать оттого, что так бывает и всё тут. В таком случае, даже если мы выполним выше перечисленные две рекомендации, всё равно может возникнуть ситуация, когда сервером будет выдаваться информация об одной кодировке, а в коде HTML страницы будет явно прописана уже другая кодировка. В подобном случае, пожалуй, наиболее простым решением будет следующее.

Пропишите в файл .htaccess директиву:

AddDefaultCharset Off

При использовании данной директивы, сервер просто совсем не будет отсылать заголовок с информацией о кодировке передаваемой страницы. Тогда браузеры будут отталкиваться от данных по кодировке, которые указаны явно в коде HTML на самих страницах сайта. При этом на одной странице данные могут быть в кодировке windows-1251 , а на другой странице, например в utf-8 . Главное, не забыть указать на этих страницах соответствующие мета-теги с информацией о правильной кодировке для распознавания и отображения текста браузером.

Подобное решение хоть и самое простое, но, пожалуй, не самое оптимальное и правильное. По-хорошему, нужно всю информацию на сайте и во всех разделах сайта размещать в одной и той же кодировке! И если есть несколько страниц в другой кодировке, то лучше обновить в них информацию переконвертировав все тексты в требуемую кодировку.

Ситуация вторая

Как известно, большинство сайтов при генерации страниц часть данных выбирают из базы данных, например, MySQL (если сайт написан на языке PHP). Часто, при переносе сайта с одного хостинга на другой , могут возникнуть проблемы из-за несовпадения кодировок между данными, хранящимися в базе данных MySQL, и данными, хранящимися, например, непосредственно в шаблонах сайта . Таким образом, может возникнуть такая ситуация, что при формировании одной страницы на ней могут оказаться данные в разных кодировках. Пожалуй, это одна из самых грубых возможных ошибок с кодировкой на сайте и её нужно решать сразу же. Иначе, потом могут возникнуть дополнительные сложности при наполнении и редактировании сайта.

Решение подобных разногласий с данными, хранящимися в базе данных, достигается правильной явной установкой настроек кодировки при подключении к базе данных и до выполнения выборок данных из неё. Например, если данные на сайте у нас хранятся в кодировке windows-1251, то и читать данные из базы мы должны в этой же кодировке. Для этого, после выполнения подключения к базе с помощью функции PHP mysql_connect() (или mysql_pconnect()) выполните следующий запрос SQL:

mysql_query("SET NAMES cp1251");

Данный запрос, сообщает серверу базы данных MySQL, что все данные хранятся и должны передаваться в кодировке cp1251 (именно такое название кодировки используется в MySQL вместо упоминаемого ранее названия windows-1251, которое используется при передачи данных HTML).

Задаём набор символов

Мета-тег

Нужно добавить на каждую страницу (или в шаблон шапки) специальный мета-тег, сообщающий браузеру о том, какой набор символов ему использовать для отображения текстов. Тег этот стандартный и выглядит обычно так:

charset=UTF-8 » />

charset=»utf-8″ /> (вариант для HTML 5)

Надо вставить его в раздел — лучше в самое начало, сразу после открывающего :

Мета-тег кодировки

Через.htaccess (если ничего не помогает)

Обычно первых двух вариантов достаточно и браузеры отображают текст как надо . Но с некоторыми из них могут быть проблемы и поэтому можно прибегнуть к помощи файла.htaccess .

Для этого в нём нужно прописать такую строчку:

AddDefaultCharset utf-8

Вот и всё. Если вы примените последовательно 3 этих способа задания кодировки на своём проекте, то вероятность того, что всё будет отображено как надо , близка к 100 %.

Как «увидеть», что скрывается за непонятными символами на сайте?

Если вы зашли на веб-страницу, видите «кракозябры» и хотите увидеть нормальный текст, то тут только два пути:

• сообщить сайтовладельцу, чтобы всё настроил как следует
• попытаться угадать кодировку самостоятельно. Делается это стандартными средствами браузеров. В Chrome, например, нужно в меню щёлкнуть «Инструменты => Кодировка» и из огромного списка выбрать подходящий набор символов (т.е. угадать).

К счастью, практически все современные веб-проекты делаются в кодировке UTF-8, которая является «универсальной» для разных алфавитов и поэтому всё менее и менее вероятно увидеть эти непонятные символы в Интернет.

Практический каждый новичок в области веб-разработок, рано или поздно сталкивается с проблемами кодировки в своих проектах. И тогда, как по написанному сценарию, начинается бомбардировка форумов с вопросами о том, как победить ненавистные "кракозябры ". Подавляющее большинство проблем уже давно известны и лечатся довольно легко, нужно просто знать "в каком месте болит и какую таблетку принять ". Посему, предлагаю разобрать наиболее популярные ошибки, из-за которых эта проблемка появляется и возможно, что мои рекомендации избавят вас от дальнейших с ними столкновений.

Во-первых, настоятельно рекомендую, чтобы все документы были в одной кодировке и база данных, а именно поля со строковыми данными, имели такую же кодировку. Устанавливается она при создании базы или же можно указывать сравнение для каждого отдельного поля. Если создаёте БД с помощью phpMyAdmin, то сложностей возникнуть не должно: закладка "Базы данных" > в поле под "Создать базу данных" вписываете имя вашей будущей БД > рядом выпадающий список "Сравнения". Если же создаёте базу sql-запросом, то пишите примерно следующее:

CREATE DATABASE IF NOT EXISTS `my_db_name` CHARACTER SET utf8 COLLATE utf8_general_ci;

Выбор кодировки остаётся за вами, но я бы посоветовал выбрать для документов "UTF-8 без BOM " и сравнение для базы "utf8_general_ci " (юникод многоязычный, регистронезависимый ). Только не забудьте подстраховаться и сделать дамп перед манипуляциями с БД! Не буду здесь расписывать, что такое BOM , но если о-о-очень образно и на пальцах, то это такой невидимый маркер, который планировался для различения кодировок UTF-16LE и UTF-16BE, но по некоторым причинам оказался невостребованным и теперь мешает веб-разработчикам жить спокойно;) Выглядит BOM, как символ U+FEFF и селится в начале документа. А почему всё-таки UTF-8? Вот, хотя бы пара причин... Вы без проблем сможете выводить на экран как кириллицу, так и цитату из стихов Аль-Мутанабби или китайские иероглифы. Всё потому, что в той же кодировке windows-1251 (cp1251) всего лишь 256 символов, в то время, как в UTF-8 их около ста тысяч, плюс ко всему специальные символы, пиктограммы, значки и т.д. Если вы собираетесь использовать на своём сайте ajax-запросы, то это так же добавляет плюс к кодировке UTF-8, потому что именно с этой кодировкой дружит объект XMLHttpRequest, а с другими придётся извращаться и иногда безуспешно. Та же карта сайта (sitemap.xml), которая служит для индексации поисковыми системами, работает только, если этот файл создан с кодировкой UTF-8. Кроме того, эта кодировка является стандартом для работы многих функций PHP и стандартом, который рекомендован W3C .

При создании нового документа - всё ясно, а как быть с уже существующим, в котором желательно изменить кодировку? Один из самых простых способов - это открыть документ в Notepad++ , выбрать в меню "Кодировки " и в списке "Преобразовать в UTF-8 без BOM ". Далее изменяем метатег с определением кодировки:

И для php-файлов можно установить соответствующий заголовок, но только, если файл не подключен в другом документе, где такой заголовок уже будет отправлен раньше. Это касается как заголовка в метатеге, так и отправленного функцией header:

Header("Content-Type: text/html; charset=utf-8");

Проверяем результат в браузере. Тут может несколько вариантов:

1. Всё выводится отлично и вопрос закрыт
2. Статически прописанные данные отображаются нормально, но данные из БД - всё тами же "кракозябрами"
3. Ничего не изменилось и кодировка осталась кривой

Начнём с последнего пункта. Счастливые владельцы выделенных серверов или VPS/VDS, могут изменить кодировку для директивы default_charset в конфигурационном файле php.ini. Тем же, кто доступа к php.ini не имеет или имеет, но необходимо изменить кодировку только для одного сайта, можно использовать файл.htaccess, записав в него следующее:

# в принципе, хватает строки ниже: AddDefaultCharset UTF-8 # но иногда, могут потребоваться дополнительные установки: DefaultLanguage ru php_value default_charset "utf-8"

Файл.htaccess распологается в корне вашего сайта. Если вы его там не обнаружили, то создаём сами. В обычном блокноте создаёте документ > "Сохранить как " > Тип файла выбрать "Все файлы " > в поле "Имя файла" записываем только точку и расширение ".htaccess ".

Переходим ко второму пункту - если базу перевели на нужную кодировку, но данные из неё отображаются на странице криво. Для начала, нужно убедится, что символы в самой базе отображаются нормально. Если кодировка там "не поплыла", то можно или же опять апеллировать к файлам конфигурации, или сделать запрос сразу после подключения к базе:

SET NAMES utf8;

* я пишу сам текст запроса, но т.к. не знаю какое расширение вы используете для работы с MySQL, покажу несколько вариантов:

// для устаревшего mysql_* $db = mysql_connect("localhost", "username", "password"); mysql_select_db("db_name", $db); mysql_query("SET NAMES utf8"); // для PDO и версий php ниже 5.3.6 $dbh = new PDO("mysql:host=localhost;dbname=db_name", "username", "password"); $dbh->exec("SET NAMES utf8"); // для PDO и версий php 5.3.6 и новее, можно указывать прямо при создании объекта $dbh = new PDO("mysql:host=localhost;dbname=db_name;charset=utf8", "username", "password"); // или $db = new PDO("mysql:host=localhost;dbname=db_name", "username", "password", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8")); // для MySQLi $mysqli = new mysqli("localhost", "username", "password", "db_name"); $mysqli->set_charset("utf8");

Раз уж затронул вопрос "устаревшего mysql_*", то хочу обратить ваше внимание, на текст выделенный красным в документации php. Cто́ит задуматься...
Если у вас была одна из стандартных проблем, то выполнив некоторые или все вышеописанные шаги, с кодировкой вопрос будет решен положительно. Но так же хотелось бы упомянуть о некоторых функциях, которые могут пригодится в нестандартных ситуациях. Подробнее о них вы сможете прочитать в документации, а я лишь приведу пару примеров, не вдаваясь в подробности:

Mb_internal_encoding() C помощью этой функции, мы можем установить или получить текущую кодировку скрипта: mb_internal_encoding("UTF-8"); // устанавливаем echo mb_internal_encoding(); // без аргумента - получаем mb_http_input() и mb_http_output() Две функции, которые определяют, устанавливают или получают кодировку символов HTTP запроса или вывода: print_r(mb_http_input("I")); // определяем кодировку входных данных http-запроса mb_http_output("UTF-8"); // устанавливаем кодировку для http-вывода echo mb_http_output(); // получаем текущую кодировку символов http-вывода iconv() Функция преобразовывает символы строки в нужную кодировку: echo iconv("utf-8","cp1251","Привет, РјРёСЂ!"); // Привет, мир! mb_convert_encoding() Функция похоже на iconv(), но на мой взгляд лучше, т.к. работает более адекватно. echo mb_convert_encoding("Привет, РјРёСЂ!","cp1251","utf-8"); // Привет, мир!

Да и вообще, не забываем про аналоги функций для работы с многобайтными строками . Чаще всего, они имеют такое же название, но с приставкой mb_ . Разницу ощутить достаточно просто. Возьмём, для примера, функции strlen() и mb_strlen() и проведём эксперимент, измерив длину строки:

// установим внутреннюю кодировку mb_internal_encoding("utf-8"); // для латинских символов разницы нет echo strlen("incode"); // 6 echo mb_strlen("incode"); // 6 // А вот с кириллицей выдает - пичалька echo strlen("инкод"); // 10 echo mb_strlen("инкод"); // 5

Может кому и не нужно объяснять это явление, но для новичков растолкую: кириллица кодируется двумя байтами, а strlen() считает именно количество байт в строке, а не количество букв. Вот и получается, что пять кириллических символов умножить на два - получаем 10. Китайские символы, если я не ошибаюсь, вообще кодируются тремя байтами, поэтому в дальнейшем для таких случаев, чтоб не возникало никаких недорозумений, используйте соответствующие функции.

Повторюсь, что эти решения к часто встречающимся случаям и в подавляющем большинстве, они решают проблему. Но если у вас возникла ситуация, когда всэ эти способы не возымели действия, то пишите сюда, попробуем разобраться вместе и дополним статью новым "рецептом от головной боли" ;) Засим позвольте откланяться.

Влад Мержевич

Метатеги используются для хранения информации предназначенной для браузеров и поисковых систем. Например, механизмы поисковых систем обращаются к метатегам для получения описания сайта, ключевых слов и других данных.

Метатеги для поисковых механизмов

Среди разработчиков сайтов существует мнение, что правильно написанные метатеги позволяют подняться к верхним строчкам поисковых серверов. На самом деле это не так, на одних метатегах высоко не поднимешься, но и неудачно выполненное содержимое метатегов может ухудшить рейтинг сайта.

Два метатега предназначены специально для поисковых серверов: description (описание) и keywords (ключевые слова). Некоторые вебмастера добавляли в раздел keywords ключевые слова, которые не имеют никакого отношения к теме сайта, но зато пользовались определенным успехом среди посетителей поисковиков. Однако, через некоторое время, поисковые системы научились бороться с таким явлением и проверяют содержимое веб-страницы на соответствие заявленным ключевым словам.

Некоторые принципы, относящиеся к метатегам:

• не включайте ключевые слова, которые не содержатся на ваших страницах;
• не повторяйте ключевые слова;
• используйте метатеги по их прямому назначению;
• делайте описание и список ключевых слов различными для каждой страницы сайта с учетом содержимого.

description

Большинство поисковых серверов отображают содержимое поля description (пример 1) при выводе результатов поиска. Если этого тега нет на странице, то поисковый движок просто перечислит первые встречающиеся слова на странице, которые, как правило, оказываются не очень-то и в тему.

Пример 1. Использование Description

keywords

Этот метатег был предназначен для описания ключевых слов, встречающихся на странице (пример 2). Но в результате действия людей, желающих попасть в верхние строчки поисковых систем любыми средствами, теперь дискредитирован. Поэтому многие поисковики пропускают этот параметр.

Пример 2. Использование Keywords

Ключевые слова можно перечислять через пробел или запятую. Поисковые системы сами приведут запись к виду, который они используют.

Автозагрузка страниц

Чтобы автоматически загружать новый документ через определенный промежуток времени используется инструкция http-equiv="refresh" (пример 3).

. Для операционной системы Windows и кириллицы charset обычно принимает значение utf-8 или windows-1251 (пример 4).

Пример 4. Выбор текущей кодировки

Кириллица

Если указание кодировки отсутствует, браузер пытается сам определить, какой тип символов используется в документе и выбирает необходимую кодировку автоматически. Браузер не всегда может точно распознать язык веб-страницы и в некоторых случаях предлагает вьетнамскую кодировку вместо кириллицы. По этой причине лучше всегда указывать приведенную строчку. Тем не менее, возникают обстоятельства, когда указание кодировки может принести определенный вред. Например, веб-сервер автоматически использует перекодирование данных в KOI-8, а браузер, встретив параметр charset=windows-1251 , переводит текст в кодировку Windows. Получается двойное изменение символов, прочитать такой текст не просто. К счастью, подобная проблема уже отходит в прошлое, во всяком случае, ее легко можно выявить и нейтрализовать на уровне сервера.