Кодировка сайта

Кодировка сайта (от англ. character encoding, charset) — стандарт представления символов веб-страницы в виде последовательности байтов, определяющий, как браузер интерпретирует данные при отображении текста, особенно критичный для корректного показа кириллицы, спецсимволов и языков с нелатинской письменностью.

Что такое кодировка сайта в практической работе с сайтом — это техническая настройка, от которой зависит, увидит ли пользователь нормальный русский текст или «кракозябры» (нечитаемые символы вида «Ð¿Ñ€Ð¸Ð²ÐµÑ‚»). Современный стандарт для всех новых сайтов — UTF-8, поддерживающий любые языки мира. Старые сайты на постсоветском пространстве часто использовали Windows-1251 или KOI8-R — это унаследованные кодировки эпохи до UTF-8.

Концепция кодировок возникла в 1960-х с появлением ASCII (American Standard Code for Information Interchange) — стандарта для 128 символов латиницы и базовых знаков. С распространением компьютеров за пределы англоязычного мира появились локальные кодировки: Windows-1251 для кириллицы, ISO-8859 для европейских языков, Shift-JIS для японского, GB2312 для китайского. UTF-8 (Unicode Transformation Format) был стандартизирован в 1993 году и стал универсальным решением проблемы — он покрывает все языки мира одной системой.

Сегодня по данным W3Techs, около 98% веб-сайтов в мире используют UTF-8. Оставшиеся 2% — это устаревшие проекты на старых движках, унаследованные базы данных без миграции, специализированные локальные сайты в Восточной Европе и Азии. Для нового сайта в 2025 году выбор кодировки не стоит — это всегда UTF-8.

Что такое кодировка сайта

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

Простой пример. Буква «А» в кодировке Windows-1251 — это байт 0xC0 (192 в десятичной системе). В UTF-8 эта же буква — последовательность из двух байт 0xD0 0x90. Если текст сохранён в Windows-1251, а браузер пытается прочитать его как UTF-8, то 0xC0 будет интерпретироваться как начало многобайтовой последовательности UTF-8, и вместо «А» получится «нечитаемый кракозябр».

Современный веб использует Unicode — универсальный реестр символов всех языков мира. На текущий момент Unicode описывает более 150 000 символов: латиница, кириллица, китайские иероглифы, арабская вязь, эмодзи, математические символы. UTF-8 — самый распространённый способ кодирования Unicode для веба. UTF-16 используется в Windows и Java, UTF-32 — в академических задачах.

История кодировок

Ключевые этапы развития кодировок текста:

• 1963. Принят ASCII — American Standard Code for Information Interchange. 128 символов (7 бит): латиница, цифры, базовые знаки препинания, управляющие символы.
• 1970-е. Появление расширенных версий ASCII (Extended ASCII) с 256 символами (8 бит). Разные расширения для разных языков — это ещё не стандарт, а зоопарк локальных решений.
• 1985. KOI8-R — кодировка для русского языка, стандартизированная в СССР. Использовалась в Unix-системах и ранних Linux. Особенность — при потере 8-го бита (что часто случалось в старых сетях) текст оставался читаемым латинской транслитерацией.
• 1990-е. Windows-1251 — кодировка кириллицы от Microsoft. Стала стандартом де-факто на постсоветском пространстве, потому что Windows был основной ОС.
• 1991. Утверждена первая версия Unicode 1.0 — универсальный стандарт. 16-битное представление с поддержкой ~7000 символов.
• 1993. Стандартизирован UTF-8 — формат переменной длины для кодирования Unicode. Главное преимущество — ASCII-символы кодируются одним байтом (обратная совместимость), остальные — двумя-четырьмя байтами.
• 2000-е. Постепенный переход веба с локальных кодировок на UTF-8. Доля UTF-8 в рунете: 30% к 2008, 70% к 2012, 95%+ к 2020.
• 2010-е. Появление эмодзи в Unicode (с 2010 года, версия Unicode 6.0). Это сделало UTF-8 единственным разумным выбором для современных сайтов.
• 2025. Unicode 16.0 — более 154 000 символов. UTF-8 — фактически безальтернативный стандарт для веба.

Основные кодировки в рунете

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

В рунете до 2010 года активно сосуществовали Windows-1251 и UTF-8. Сейчас Windows-1251 остаётся только на унаследованных проектах: внутренние корпоративные системы, древние CMS на ASP, базы данных, не мигрированные на Unicode. Все новые сайты создаются на UTF-8 — это умолчание в WordPress, Bitrix, Tilda, Joomla, всех современных CMS.

Как указать кодировку на сайте

Для современного сайта на UTF-8 кодировку нужно указывать в нескольких местах:

В HTML-документе. Тег `` в секции `` — обязательный для HTML5. Должен идти как можно раньше — в первых 1024 байтах документа, чтобы браузер сразу определил кодировку. Пример:

<!DOCTYPE html>
<html lang="ru">
<head>
  <meta charset="utf-8">
  <title>Заголовок страницы</title>
</head>

В HTTP-заголовке. Сервер должен отдавать заголовок `Content-Type: text/html; charset=utf-8`. Это приоритетнее `` — если заголовки сервера и HTML противоречат друг другу, браузер ориентируется на заголовок сервера. Настройка через .htaccess в Apache:

AddDefaultCharset UTF-8
AddCharset UTF-8 .html .htm .css .js

В Nginx это указывается в конфиге сайта:

charset utf-8;

В файле страницы. Сам HTML-файл должен быть сохранён в UTF-8. Если файл сохранён в Windows-1251, а в meta-теге указано UTF-8 — будут кракозябры. Все современные редакторы (VS Code, Sublime Text, PHPStorm) по умолчанию сохраняют в UTF-8.

В базе данных. Если сайт использует MySQL/MariaDB — должна быть кодировка `utf8mb4` (поддерживает четырёхбайтные символы, в том числе эмодзи) с collation `utf8mb4_unicode_ci`. Старый формат `utf8` в MySQL поддерживает только 3 байта — не работает с эмодзи и некоторыми редкими символами.

В коде PHP. Функция `mb_internal_encoding(‘UTF-8’)` в начале скрипта обеспечивает корректную работу строковых функций с многобайтными символами.

Проблемы с кодировкой — кракозябры

«Кракозябры» — народное название неправильно отображаемого текста. Типичные виды:

• «Ð¿Ñ€Ð¸Ð²ÐµÑ‚» — UTF-8 текст интерпретируется как Windows-1251.
• «пр?в?т» с вопросами — кодировки не соответствуют, неотображаемые символы заменяются.
• Иероглифы вместо кириллицы — UTF-8 интерпретируется как Big5 или Shift-JIS.
• Каждая буква занимает 2 символа странного вида — текст в UTF-8, а браузер думает что Latin-1.

Причины проблем:

1. Несовпадение meta и HTTP-заголовков. На сайте написано UTF-8, сервер отдаёт Windows-1251 (или наоборот).
2. Файл сохранён не в той кодировке. CMS работает с UTF-8, но кто-то правил файлы шаблона в редакторе, сохраняющем в Windows-1251.
3. База данных в другой кодировке. Сайт UTF-8, БД — Windows-1251. При выводе текста из БД получаются кракозябры.
4. BOM (Byte Order Mark). Файл сохранён с BOM-меткой UTF-8. Это первые три байта `EF BB BF` в начале файла. На современных серверах вызывает проблемы — пустые строки, выходящие до отправки HTTP-заголовков.
5. Старые скрипты. Legacy-код на PHP без `mb_string` функций ломает многобайтные символы при обрезке строк или подсчёте длины.

Миграция со старой кодировки на UTF-8

Если сайт работает на Windows-1251 — переход на UTF-8 рекомендован, но требует аккуратной работы:

1. Бэкап. Полный бэкап файлов и базы данных до начала миграции. Это обязательно.
2. Конвертация файлов. Перекодирование всех HTML, PHP, CSS, JS, TXT-файлов из Windows-1251 в UTF-8. Через скрипты (iconv в Linux) или batch-конвертеры (Notepad++ массово).
3. Конвертация базы данных. Дамп БД через mysqldump, перекодирование дампа через iconv, импорт обратно с настройкой `–default-character-set=utf8mb4`.
4. Обновление meta-тегов. Замена `` на `` во всех шаблонах.
5. Обновление .htaccess. Замена `AddDefaultCharset windows-1251` на `AddDefaultCharset UTF-8`.
6. Тестирование. Проверка всех страниц на корректное отображение. Особое внимание формам, поиску по сайту, динамическому контенту.
7. Старые URL. Если URL содержали кириллицу в encoded виде, они могут поменяться после миграции. Это критично для SEO — нужны 301-редиректы со старых URL на новые.

Стоимость миграции среднего сайта (1000 страниц, CMS, БД): 500–2000 USD при работе через подрядчика, или 1–3 дня собственными ресурсами. Окупаемость — мгновенная: устраняются проблемы с кракозябрами для пользователей и снимаются риски для SEO.

Кодировка и SEO

Влияние кодировки на SEO работает через несколько каналов:

Индексация. Поисковые боты Google и Яндекса корректно индексируют контент только при правильно указанной кодировке. Сайт с кракозябрами для бота — это сайт со «странным» контентом, который алгоритм не понимает. Такой сайт не получит позиции по русскоязычным запросам.

Сниппеты в выдаче. Если на сайте кодировочные ошибки, в выдаче Google/Яндекса сниппет может отображаться кракозябрами или обрезанными символами. Это снижает CTR и доверие пользователей.

URL с кириллицей. URL могут содержать кириллицу в двух форматах — encoded (`%D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82`) или в Punycode для доменов (`xn--80ahe2cv`). Современные поисковики корректно работают с обоими, но в выдаче читаемые ЧПУ предпочтительнее.

Кодировка и Core Web Vitals. Сайты без указания кодировки в первых байтах HTML могут получить штраф по LCP — браузер не может начать рендеринг, пока не определит кодировку. Поэтому `` должен идти первым в ``.

Часто задаваемые вопросы

Какую кодировку выбрать для нового сайта?

Только UTF-8. Это стандарт всех современных систем, поддерживает любые языки и эмодзи, корректно работает со всеми браузерами и поисковыми системами. Альтернативы рассматривать не нужно — Windows-1251, KOI8-R, ISO-8859 — это исторические артефакты, их использование сегодня создаёт только проблемы.

Чем utf8 отличается от utf8mb4 в MySQL?

utf8 в MySQL — это исторически некорректная реализация UTF-8, поддерживающая только символы до 3 байт. Эмодзи (которые требуют 4 байт) в utf8 не помещаются и заменяются вопросительными знаками. utf8mb4 — полноценный UTF-8 с поддержкой всех 4 байт. Современная рекомендация — использовать только utf8mb4 для новых проектов.

Как проверить кодировку сайта?

Несколько способов. В браузере Chrome: View → Encoding покажет кодировку (но в новых версиях скрыто, нужны DevTools). Через curl: `curl -I https://example.com` покажет HTTP-заголовки сервера. Через онлайн-сервисы (validator.w3.org или charset-checker.com). Для DevTools — открыть Network, выбрать запрос документа, посмотреть Response Headers — там `Content-Type` с указанием кодировки.

Что такое BOM и нужен ли он?

BOM (Byte Order Mark) — три байта `EF BB BF` в начале UTF-8 файла, используемые для пометки кодировки. В вебе BOM не нужен и часто вреден — он добавляет невидимые символы перед HTML, что может вызвать проблемы с заголовками PHP (Headers already sent), смещение layout в CSS, ошибки парсинга JS. Рекомендация — сохранять файлы в UTF-8 БЕЗ BOM.

Что делать, если на сайте появились кракозябры?

Первое — определить, где ошибка: в файлах, в БД, в meta-теге или в HTTP-заголовках. Через curl смотрим заголовки сервера. Через DevTools браузера проверяем meta-тег. Открываем файл шаблона в редакторе и смотрим, в какой кодировке он сохранён. Если кракозябры только в данных из БД — проблема в кодировке таблиц БД. Решение зависит от конкретной причины — обычно за полчаса–час исправляется.

Можно ли использовать на одном сайте разные кодировки на разных страницах?

Технически — да, каждая страница может иметь свой ``. На практике — это очень плохая идея. Браузеры и поисковики путаются, формы могут отправлять данные не в той кодировке, ссылки между страницами с разными кодировками работают непредсказуемо. Стандартная рекомендация — один сайт, одна кодировка (UTF-8) на всех страницах.