Український текст без зіпсованих літер: перевірка UTF-8

Замість українського заголовка видно «Ð…», знаки питання або ромби зі знаком заміни. Не починайте з вибору іншого шрифту. Спершу потрібно з’ясувати, на якому етапі текст перестав відповідати своїм байтам: у файлі, під час експорту, у відповіді сервера чи вже під час відображення. Цей порядок допомагає не зіпсувати джерело повторним збереженням.

Розділіть три різні налаштування

Кодування описує спосіб запису символів у байтах. Мова документа описує мову тексту. Шрифт визначає форму знаків і доступні гліфи. Атрибут lang="uk" корисний для україномовної сторінки, але не перетворює Windows-1251 на UTF-8. Так само встановлення кириличного шрифту не виправляє текст, який уже був неправильно декодований і збережений.

Для нового HTML-документа використовуйте UTF-8 і реально зберігайте файл у цьому кодуванні. Оголошення meta charset розташуйте на початку head: воно має повністю потрапляти в перші 1024 байти документа. Якщо сервер також передає кодування через Content-Type, значення повинні збігатися. Заголовок HTTP має вищий пріоритет за внутрішнє оголошення.

<!doctype html>
<html lang="uk">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Український документ</title>
</head>
<body><h1>Ґанок, їжак, Європа й апостроф ’</h1></body>
</html>

Збережіть незмінний оригінал

Перед конвертацією старої сторінки зробіть копію її початкових байтів. Не відкривайте її з невідомим кодуванням, не зберігайте поверх і не пробуйте кілька перетворень поспіль. Після такого ланцюжка вже важко відрізнити помилку джерела від помилки останньої спроби. Зручно мати окремі файли «джерело», «кандидат UTF-8» і короткий запис про вибране початкове кодування.

Надійніше шукати підказки в старому meta, заголовках архівної відповіді та налаштуваннях попередньої системи. Автоматичне визначення — підказка, яку потрібно перевірити на справжніх словах. Для української обов’язково перегляньте Ґ, Є, І, Ї, м’який знак, типографський апостроф і лапки, а також імена та підписи в кінці документа.

Перевірте файл і публічну відповідь окремо

Суворе декодування виявляє байти, які не відповідають UTF-8. Наведена команда читає файл без перезапису й завершиться помилкою, якщо кодування некоректне. Водночас успішний результат не доводить, що слова правильні: вже спотворений текст теж може бути коректним UTF-8.

python3 - <<'PY_CHECK'
from pathlib import Path
text = Path("index.html").read_bytes().decode("utf-8", errors="strict")
print("UTF-8 читається; символів:", len(text))
print("Символів заміни U+FFFD:", text.count("\uFFFD"))
PY_CHECK

curl --silent --show-error -I https://example.org/

Другий запит показує заголовки публічного сервера; замініть адресу своєю. Перевірте Content-Type, але також відкрийте сам документ у браузері. Якщо локальна копія правильна, а сайт ні, порівняйте отриманий HTML із тим, що завантажували. Причиною може бути інший файл у каталозі публікації, старий кеш або серверне оголошення кодування.

Не лікуйте втрату даних косметикою

Коли замість літери в сам файл уже записано звичайний знак питання, зміна charset не відновить початкову літеру. Потрібна резервна копія, архівний знімок або повторний експорт із джерела. Так само не варто замінювати всю кирилицю HTML-сутностями лише для приховування невідомої причини: це ускладнить редагування й залишить проблему в інших полях.

• Початковий файл збережений окремо й не перезаписаний.
• Кандидат строго декодується як UTF-8.
• Слова, внутрішні якорі та адреси посилань звірені з оригіналом.
• HTTP-заголовок і meta charset не суперечать один одному.
• Перевірена публічна адреса, включно з текстом унизу сторінки.

Для архіву важлива й прозорість: виправлення кодування не означає літературного редагування перекладу. Запишіть, що саме змінювали, і збережіть авторське застереження. Тоді майбутній читач зможе відрізнити історичне формулювання від технічної помилки відновлення.