<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.