<meta charset = "utf-8"> vs <meta http-equiv = "Тип вмісту">


1535

Для того, щоб визначити схему для Doctype HTML5 , яку позначення я повинен використовувати?

  1. Короткий:

    <meta charset="utf-8" /> 
  2. Довго:

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

94
Використання тегу <meta> для чогось типу типу вмісту та кодування є дуже іронічним, оскільки, не знаючи цих речей, ви не змогли розібрати файл, щоб отримати значення метатега.
Марк

321
Ви можете розбирати його як ASCII, поки не дістанетесь до нього. Алгоритм розбору HTML5 враховує це.
Квентін

41
Помічено, що жоден з них не використовується для розбору, коли сторінка подається через Інтернет. Замість цього Content-Typeвикористовуватиметься заголовок відповіді HTTP . Метатег використовується лише тоді, коли сторінка завантажується з файлової системи локального диска.
BalusC

38
Мета-елемент використовується через HTTP за певних умов (включаючи відсутність даних, що знаходяться в заголовку HTTP)
Квентін

78
Іронічно також, що він називається charset, коли він дійсно призначений для визначення кодування. (шаблоном є Unicode, кодування - UTF-8)
Райан

Відповіді:


1084

У HTML5 вони еквівалентні. Використовуйте коротший, його легше запам’ятати та набрати. Підтримка браузера чудово, оскільки вона була розроблена для зворотної сумісності.


23
А як щодо підтримки браузера? Чи <meta charset='utf-8'>працює в IE6?
Šime Vidas

11
Наскільки я знаю, так.
Квентін

4
Ось оновлене посилання на сторінку коду Google, яку згадував @ Šime Vidas. Він говорить про IE 6, 7 і 8: "У браузерах, які не є IE, ви можете використовувати document.characterSet. В IE ви можете подумати, що ви могли б document.getElementsByTagName ('meta') [0] .charset, але це повертає лише кодування символів, яке ви вказали, а не кодування, яке фактично використовує IE. "
hotshot309

7
Я знаю, що цей потік старий, але gtmetrix.com/specify-a-character-set-early.html вказує, що використання <meta>кодування символів відключає завантажувач lookahead в IE8, що може вплинути на завантаження сторінки. Так, так, я знаю ... падіння IE8. @ MészárosLajos може повернутися сюди через пару років і переграти наші кулі для підтримки IE8. ;-)
erturne

3
Сьогодні у мене виникла проблема, коли корейські символи не відображалися в IE11. Скасування короткого синтаксису на користь довшого синтаксису вирішило проблему. Я не знаю, чи це через якусь конфігурацію сервера, чи це проблема з IE11 та колом. Точна комбінація символів, на якій вона провалювалася, була 베라.
Джеймс Доннеллі

250

Обидві форми мета-діаграми оголошень еквівалентні і повинні працювати однаково у веб-переглядачах. Але є кілька речей, які потрібно пам’ятати, оголошуючи набір символів веб-файлів як UTF-8:

  1. Зберегти файл (и) в UTF-8 кодуванні без з позначки порядку байтів (BOM).
  2. Задекларуйте кодування у ваших HTML-файлах за допомогою мета-діаграми (як вище).
  3. Ваш веб-сервер повинен обслуговувати ваші файли, оголошуючи кодування UTF-8 у заголовку HTTP-вмісту.

Сервери Apache налаштовані для обслуговування файлів у ISO-8859-1 за замовчуванням, тому вам потрібно додати наступний рядок у .htaccessфайл:

AddDefaultCharset UTF-8

Це налаштує Apache для сервісу ваших файлів, декларує кодування UTF-8 у заголовку відповіді Content-Type, але для початку ваші файли повинні бути збережені в UTF-8 (без BOM).

Блокнот не може зберігати ваші файли в UTF-8 без BOM. Безкоштовний редактор, який може бути Notepad ++ . На панелі меню програми виберіть "Кодування> Кодування в UTF-8 без BOM". Ви також можете відкрити файли та повторно зберегти їх у UTF-8, використовуючи "Кодування> Перетворити на UTF-8 без BOM".

Детальніше про марку порядку байтів (BOM) у Вікіпедії .


20
@CodeBoy Я б змінив вашу відповідь, щоб сказати "Ви повинні зберегти ... без BOM". На наступній сторінці написано: "... як правило, найкраще для оперативної сумісності опускати BOM ...", вказуючи кращу практику, але не вимогу: w3.org/International/questions/qa-byte-order-mark
Йоганн

3
У IIS ви можете встановити набір шаблонів у заголовках HTTP за допомогою <globalization fileEncoding = "utf-8" responseEncoding = "utf-8" /> у Web.Config - додати його до <system.web>
Кріс Москіні

3
як я розумію речі, це не має значення НА ВСІХ, якщо ви економите з нашими без BOM.
Девід 天宇 Вонг

3
Чому, на вашу думку, HTML UTF-8 не повинен бути BOM. Мати BOM має добре працювати. Крім того, вам не потрібен metaі HTTP-заголовок. Вам просто потрібен один із BOM metaабо HTTP-заголовка.
hsivonen

5
Summing up: don't use BOM for UTF-8Я не можу з цим погодитися. BOM в UTF-8 дуже корисний для сигналізації про тип кодування. Інакше ми мусимо здогадуватися чи використовувати такі речі, як метатеги, до яких відноситься це питання. Класна річ у BOM - це те, що вона є частиною специфікації Unicode і тому може бути використана для всіх даних, закодованих у Unicode, а не лише для HTML. Що ми повинні зробити, це використовувати BOMs скрізь, нехай застаріле програмне забезпечення підірветься на ньому, повідомте про ці помилки та виправте їх.
Штійн де Вітт

82

Ще одна причина, коли йдеться про короткий, - це те, що він відповідає іншим випадкам, коли ви можете вказати набір символів у розмітці. Наприклад:

<script type="javascript" charset="UTF-8" src="/script.js"></script>

<p><a charset="UTF-8" href="http://example.com/">Example Site</a></p>

Послідовність допомагає зменшити помилки та зробити код більш читабельним.

Зауважте, що атрибут charset нечутливий до регістру. Можна використовувати UTF-8 або utf-8, однак UTF-8 чіткіший, читабельніший, точніший.

Крім того, абсолютно немає причин використовувати будь-яке значення, крім UTF-8, в атрибуті мета-діаграми або заголовку сторінки. UTF-8 - це кодування за замовчуванням для веб-документів, починаючи з HTML4 у 1999 році, і єдиний практичний спосіб створення сучасних веб-сторінок.

Крім того, ви не повинні використовувати HTML-об'єкти в UTF-8. Такі символи, як символ авторського права, слід вводити безпосередньо. Єдині об'єкти, які ви повинні використовувати, - це 5 зарезервованих символів розмітки: менше, більше, ніж, ampersand, prime, double prime. Суб'єктам потрібен парний HTML-аналіз, який ви не завжди можете використовувати вперед, вони вводять помилки, роблять ваш код менш читабельним, збільшують розміри файлів, а іноді неправильно декодують у різних браузерах залежно від того, які сутності ви використовували. Дізнайтеся, як вводити / вставляти авторські права, торговельну марку, відкриту цитату, закривати цитату, апостроф, ем тире, анш, куля, євро та будь-які інші символи, які ви зустрічаєте у своєму вмісті, і використовуйте ці фактичні символи у своєму коді. У Mac є переглядач символів, який можна ввімкнути в налаштуваннях системи клавіатури, і ви можете знайти, а потім перетягнути потрібні символи або скористатися відповідним засобом перегляду клавіатури, щоб побачити, які клавіші ввести. Наприклад, торгова марка - Опція + 2. UTF-8 містить усі символи та символи кожної писемної людської мови. Тож немає приводу для використання - замість ем тире. Непогано також вивчити правила пунктуації та типографіки ... наприклад, знаючи, що період проходить всередині близької цитати, а не зовні.

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

Ні, це неправда. Браузер починає розбирати файл як кодування браузера за замовчуванням, або UTF-8 або ISO-8859-1. Оскільки US-ASCII є підмножиною ISO-8859-1 і UTF-8, браузер може читати просто чудово в будь-якому випадку ... це те саме. Коли браузер стикається з тегом мета-діаграми, якщо кодування відрізняється від того, що браузер вже використовує, браузер перезавантажує сторінку у вказаному кодуванні. Ось чому ми ставимо тег мета-діаграми вгорі, відразу після тегу заголовка, перш ніж все інше, навіть назву. Таким чином ви можете використовувати символи UTF-8 у своєму заголовку.

Ви повинні зберегти свої файли в кодуванні UTF-8 без BOM

Це не зовсім суто. Якщо у вашому документі є лише символи US-ASCII, ви можете зберегти його як US-ASCII та подати його як UTF-8, оскільки це підмножина. Але якщо є символи Unicode, ви правильні, ви повинні зберегти як UTF-8 без BOM.

Якщо ви хочете гарного текстового редактора, який зберігатиме ваші файли в UTF-8, рекомендую Notepad ++.

На Mac використовуйте TextWrangler Bare Bones TextWrangler (безкоштовно) від магазину додатків Mac, або Bare Bones BBEdit, який знаходиться в магазині Mac App за 39,99 доларів… дуже дешево за такий чудовий інструмент. У будь-якому додатку є меню внизу вікна документа, де ви вказуєте кодування документа, і ви можете легко вибрати "UTF-8 no BOM". І звичайно, ви можете встановити це як за замовчуванням для нових документів у налаштуваннях.

Але якщо ваш веб-сервер обслуговує кодування в заголовку HTTP, що рекомендується, обидва [метатеги] не потрібні.

Це неправильно. Звичайно, слід встановити кодування в заголовку HTTP, але також слід встановити його в атрибуті мета-діаграми, щоб користувач міг зберегти сторінку з веб-переглядача на локальному сховищі, а потім пізніше відкрити знову, і в цьому випадку єдиний показник кодування, який буде присутній, - це атрибут мета-діаграми. Ви також повинні встановити базовий тег з тієї ж причини ... на сервері базовий тег не є потрібним, але коли він відкривається з локального сховища, базовий тег дає змогу сторінці працювати так, ніби вона є на сервері, з усіма активи на місці тощо, без розривів зв’язків.

AddDefaultCharset UTF-8

Або ви можете просто змінити кодування певних типів файлів, наприклад:

AddType text/html;charset=utf-8 html

Порада для обслуговування файлів UTF-8 та Latin-1 (ISO-8859-1) полягає в наданні файлам UTF-8 розширення "text" та файлів Latin-1 "txt".

AddType text/plain;charset=iso-8859-1 txt
AddType text/plain;charset=utf-8 text

Нарешті, розгляньте Збереження документів із закінченнями рядків Unix, а не застарілими DOS або (класичними) кінцями рядків Mac, які не допомагають і можуть зашкодити, особливо вниз по лінії, коли ми отримуємо все далі та далі від цих застарілих систем. HTML-документ із дійсним кодуванням HTML5, UTF-8 та закінченнями рядків Unix - це добре виконана робота. Ви можете ділитися та редагувати, зберігати та читати та відновлювати та покладатися на цей документ у багатьох контекстах. Це lingua franca. Це цифровий папір.


20
"Якщо у вашому документі є лише символи ISO-8859-1, ви можете зберегти його як ISO-8859-1 і подати його як UTF-8, оскільки це підмножина" - неправильно. Було б правильно, якщо ви зміните "ISO-8859-1" на "US-ASCII". US-ASCII сумісний з UTF-8, оскільки це підмножина, ISO-8859-1 - ні. Щоб перетворити ISO-8859-1 (містить символи, що не належать до ASCII), до UTF-8, вам потрібно буде кодувати символи, що не належать до ASCII. Кодові точки для ISO-8859-1 існують в Unicode, але UTF-8 кодує ті, що знаходяться за межами US-ASCII, інакше, ніж ISO-8859-1.
thomasrutter

2
Ваша думка про сутності HTML хороша. У минулому я використовував об'єкти лише для того, щоб виявити, що вони були перетворені на свої символи UTF-8 після збереження в різних системах та / або відкриття в різних редакторах. Однак варто зазначити, що нерозривні пробіли (& nbsp;) можуть створювати заплутані результати, оскільки ви зазвичай не бачите їх у своєму редакторі, тому, як правило, найкраще зберігати їх як сутність для ясності (на мій досвід).
кальмар

"You should also set a base tag..."Потрібно поставитись із описаними тут застереженнями .
Мафуба

Ще одна причина, по якій ви можете віддати перевагу HTML-сутностям - це якщо ви використовуєте щось на зразок іоніконів . Я вважаю за краще &#xf101;гліф за замовчуванням, або якийсь дивний символ, якого я не впізнаю.
Даніель Любаров

30

<meta charset="utf-8"> було введено за допомогою / для HTML5.

Як зазначено в документації, обидва є дійсними. Однак, <meta charset="utf-8">це лише для HTML5 (і простіше набрати / запам'ятати).

Згодом старий стиль невдовзі стане застарілим . Я б дотримувався нового <meta charset="utf-8">.

Є лише один шлях, але вгору. У випадку з технікою, це припиняє роботу старого (дійсно, РЕАЛЬНО швидко)

Документація: Атрибут мета-діаграми HTML - W3Schools


2
Щодо посилання, будь ласка, дивіться meta.stackoverflow.com/questions/280478/why-not-w3schools-com
tripleee

18

Не заперечуючи інших відповідей, я вважаю, що варто згадати наступне.

  1. http-equivПозначення "довге" ( ) і "коротке" рівні, що б виграв перший;
  2. Заголовки веб-сервера замінять усі <meta>теги;
  3. BOM (позначка порядку в байтах) перекриє все , і в багатьох випадках це вплине на html 4 (і, ймовірно, також інші речі);
  4. Якщо ви не декларуєте жодне кодування, ви, ймовірно, отримаєте свій текст у "резервному кодуванні тексту", визначеному вашим браузером. Ні в Firefox, ні в Chrome це utf-8;
  5. За відсутності інших підказок, браузер намагатиметься прочитати ваш документ так, як ніби він був у ASCII, щоб отримати кодування, тому ви не можете використовувати будь-які дивні кодування (хоч utf-16 з BOM повинен робити);
  6. Хоча технічні характеристики говорять про те, що декларація кодування повинна знаходитись у перших 512 байтах документа, більшість браузерів намагаються прочитати більше цього.

Ви можете перевірити, запустивши echo 'HTTP/1.1 200 OK\r\nContent-type: text/html; charset=windows-1251\r\n\r\n\xef\xbb\xbf<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta charset="windows-1251"><title>привет</title></head><body>привет</body></html>' | nc -lp 4500і вказуючи веб-переглядач localhost:4500. (Звичайно, ви захочете змінити або видалити частини. Частина BOM є \xef\xbb\xbf. Будьте уважні до кодування вашої оболонки.)

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


1
Хороші моменти, але чи можете ви детально розказати, про які проблеми безпеки ви звертаєтесь?
Armfoot

1
Довга нотація не повинна перекривати коротку - просто перша в документі повинна виграти.
gsnedders

1
@Armfoot Раніше виникали проблеми з UTF-7тим, що я пам’ятаю. Також нюхання в Інтернеті, як правило, погано, наприклад, коли ви завантажуєте зображення, яке нюхається як вміст сценарію.
phk

@gsnedders випробуваний на хромі та firefox, ви маєте рацію. відповідним чином відредагував відповідь. Armfoot: мова йшла про якесь 7-бітове кодування, не пам'ятаю, що саме.
білка

1
@CraigMcQueen майже впевнений, що у відновленні браузера все ще (у 2018 році) за замовчуванням є західноєвропейський у Західній Європі, тому я вважаю, що він за замовчуванням застосовується до будь-якого кодування, що передусім кодує, було домінуючим у кожному регіоні. Користувачі можуть встановити резервну копію на utf-8, але це просто розкриває всі шалені кодування, тисячі сайтів як і раніше використовуються як блискучі високобайтові символи ascii в усьому світі, тому це все ще не часто. Більше шкода. Не бачите, як це зміниться без невеликого примусу з боку постачальників браузерів, і вони не прагнуть порушити застарілі речі.
brennanyoung

13

Використовуйте <meta charset="utf-8" />для веб-браузерів при використанні HTML5.

Використовуйте <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />під час використання HTML4 або XHTML або для застарілих аналізаторів dom, як DOMDocumentу php 5.3


2

Є деякі новини, засновані на Mozilla Foundation та sitepoint

Не використовуйте це значення ( http-equiv=content-type), оскільки воно застаріле. Віддайте перевагу charsetатрибуту на metaелементі < >. введіть тут опис зображення


о, нарешті, щось трохи пізніше
Айяш

1

Щоб вставити підпис на електронному листі, я використовував би довгу версію:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Причина полягає в тому, що не багато читачів електронної пошти використовують html5, тому завжди краще використовувати старі стилі HTML. Насправді, краще використовувати таблиці, ніж divs + css.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.