<meta charset = „utf-8”> vs <meta http-equiv = „Content-Type”>


1535

Której notacji należy użyć do zdefiniowania zestawu znaków dla HTML5 Doctype ?

  1. Krótki:

    <meta charset="utf-8" /> 
  2. Długo:

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

94
Używanie znacznika <meta> do czegoś takiego jak typ zawartości i kodowanie jest wysoce ironiczne, ponieważ bez znajomości tych rzeczy nie można przeanalizować pliku w celu uzyskania wartości metatagu.
Mark

321
Możesz go parsować jako ASCII, dopóki go nie osiągniesz. Algorytm analizujący HTML5 bierze to pod uwagę.
Quentin

41
Należy zauważyć, że żadne z nich nie jest używane do analizowania, gdy strona jest wyświetlana w Internecie. Zamiast tego Content-Typezostanie użyty nagłówek odpowiedzi HTTP . Metatag jest używany tylko wtedy, gdy strona jest ładowana z lokalnego systemu plików dysku.
BalusC

38
Meta element jest używany przez HTTP pod pewnymi warunkami (w tym brak danych znajdujących się w nagłówku HTTP)
Quentin

78
Ironiczne jest również to, że nazywa się on charset, kiedy tak naprawdę służy do określania kodowania. (zestaw znaków to Unicode, kodowanie to UTF-8)
Ryan

Odpowiedzi:


1084

W HTML5 są one równoważne. Użyj krótszego, łatwiej jest zapamiętać i wpisać. Obsługa przeglądarki jest w porządku, ponieważ została zaprojektowana pod kątem zgodności z poprzednimi wersjami.


23
Co z obsługą przeglądarki? Czy <meta charset='utf-8'>działa w IE6?
Šime Vidas

11
O ile mi wiadomo, tak.
Quentin

4
Oto zaktualizowany link do strony Google Code, o której wspomniał @ Šime Vidas. Mówi, w odniesieniu do IE 6, 7 i 8, „W przeglądarkach innych niż IE możesz użyć document.characterSet. W IE możesz pomyśleć, że możesz document.getElementsByTagName ('meta') [0] .charset, ale to zwraca tylko kodowanie znaków określone przez użytkownika, a nie kodowanie, którego faktycznie używa IE. ”
hotshot309

7
Wiem, że ten wątek jest stary, ale gtmetrix.com/specify-a-character-set-early.html wskazuje, że użycie <meta>zestawu znaków do kodowania znaków wyłącza przeglądarkę lookahead w IE8, co może mieć wpływ na czas ładowania strony. Tak, tak, wiem ... upuść IE8. @ MészárosLajos może tu wrócić za kilka lat i zepsuć nasze jaja za to, że nadal wspiera IE8. ;-)
erturne

3
Dzisiaj miałem problem, w którym koreańskie symbole nie pojawiały się w IE11. Usunięcie krótkiej składni na rzecz dłuższej składni rozwiązało problem. Nie wiem jednak, czy jest to spowodowane jakąś konfiguracją serwera, czy jest to problem z IE11 i zestawem znaków. Dokładna kombinacja symboli, na której zawiodła, to 베라.
James Donnelly,

250

Obie formy deklaracji meta charset są równoważne i powinny działać tak samo w różnych przeglądarkach. Jest jednak kilka rzeczy, o których należy pamiętać, deklarując zestaw znaków plików internetowych jako UTF-8:

  1. Zapisz plik (i) w kodowaniu UTF-8 bez tej znacznikiem kolejności bajtów (BOM).
  2. Zadeklaruj kodowanie w swoich plikach HTML za pomocą meta-zestawu znaków (jak wyżej).
  3. Twój serwer internetowy musi obsługiwać twoje pliki, deklarując kodowanie UTF-8 w nagłówku HTTP Content-Type.

Serwery Apache są domyślnie skonfigurowane do obsługi plików w ISO-8859-1, dlatego do .htaccesspliku należy dodać następujący wiersz :

AddDefaultCharset UTF-8

Spowoduje to skonfigurowanie Apache do obsługi plików deklarujących kodowanie UTF-8 w nagłówku odpowiedzi Content-Type, ale na początku pliki muszą zostać zapisane w UTF-8 (bez BOM).

Notatnik nie może zapisać plików w UTF-8 bez BOM. Darmowy edytor, którym może być Notepad ++ . Na pasku menu programu wybierz „Kodowanie> Koduj w UTF-8 bez BOM”. Możesz także otwierać pliki i ponownie zapisywać je w UTF-8 za pomocą „Kodowania> Konwertuj na UTF-8 bez BOM”.

Więcej na temat Byte Order Mark (BOM) na Wikipedii .


20
@CodeBoy Zmieniłbym twoją odpowiedź, mówiąc: „ Powinieneś oszczędzić ... bez BOM”. Następująca strona mówi „... zwykle dla interoperacyjności pominięcie BOM ...” wskazuje na najlepszą praktykę, ale nie jest to wymóg: w3.org/International/questions/qa-byte-order-mark
Johann

3
W IIS można ustawić charset w nagłówki HTTP z globalizacji fileencoding <= "UTF-8" responseEncoding = "UTF-8" /> w pliku web.config - dodaj go do <system.web>
Chris Moschini

3
jak rozumiem, w ogóle nie ma znaczenia, jeśli oszczędzasz z naszym bez BOM.
David 天宇 Wong

3
Dlaczego mówisz, że HTML UTF-8 powinien być bez BOM. Posiadanie BOM powinno działać dobrze. Nie potrzebujesz metateż nagłówka HTTP. Potrzebujesz tylko jednego z BOM metalub nagłówka HTTP.
hsivonen

5
Summing up: don't use BOM for UTF-8Nie mogę się z tym zgodzić. BOM w UTF-8 jest bardzo przydatny do sygnalizowania typu kodowania. W przeciwnym razie musimy zgadnąć lub użyć takich rzeczy jak metatagi, do których odnosi się to pytanie. Fajną rzeczą w BOM jest to, że jest on częścią specyfikacji Unicode, a zatem może być używany do wszystkich danych zakodowanych w Unicode, nie tylko HTML. To, co powinniśmy zrobić, to używać BOM wszędzie, pozwolić wysadzić je starszemu oprogramowaniu, zgłaszać te błędy i naprawiać je.
Stijn de Witt

82

Innym powodem wyboru krótkiego jest dopasowanie go do innych przypadków, w których można określić zestaw znaków w znacznikach. Na przykład:

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

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

Spójność pomaga zmniejszyć liczbę błędów i zwiększyć czytelność kodu.

Pamiętaj, że w atrybucie charset nie jest rozróżniana wielkość liter. Możesz użyć UTF-8 lub utf-8, jednak UTF-8 jest bardziej przejrzysty, czytelny i dokładny.

Ponadto absolutnie nie ma żadnego powodu, aby używać wartości innej niż UTF-8 w atrybucie meta charset lub nagłówku strony. UTF-8 to domyślne kodowanie dokumentów internetowych od HTML4 w 1999 roku i jedyny praktyczny sposób na tworzenie nowoczesnych stron internetowych.

Nie należy także używać encji HTML w UTF-8. Znaki takie jak symbol praw autorskich należy pisać bezpośrednio. Jedynymi elementami, których powinieneś użyć, są 5 zarezerwowanych znaków znaczników: mniej niż, większy niż, znak ampersand, liczba pierwsza, liczba podwójna pierwsza. Jednostki potrzebują parsera HTML, z którego nie zawsze będziesz chciał korzystać w przyszłości, wprowadzają błędy, zmniejszają czytelność kodu, zwiększają rozmiary plików, a czasem nieprawidłowo dekodują w różnych przeglądarkach, w zależności od używanych jednostek. Dowiedz się, jak wpisywać / wstawiać prawa autorskie, znaki handlowe, otwartą wycenę, zamknij wycenę, apostrof, em kreskę, kreskę, punktor, euro i wszelkie inne znaki, które napotkasz w swoich treściach, i używaj tych znaków w kodzie. Mac ma przeglądarkę znaków, którą można włączyć w Preferencjach systemowych klawiatury, i możesz znaleźć, a następnie przeciągnąć i upuścić potrzebne znaki lub użyć pasującej przeglądarki klawiatury, aby zobaczyć, które klawisze wpisać. Na przykład znakiem towarowym jest Option + 2. UTF-8 zawiera wszystkie znaki i symbole z każdego pisanego języka ludzkiego. Nie ma więc usprawiedliwienia dla użycia - zamiast kreski em. Poznanie zasad interpunkcji i typografii również nie jest złym pomysłem ... na przykład wiedząc, że kropka zawiera się w ścisłym cytacie, a nie na zewnątrz.

Użycie znacznika do czegoś takiego jak typ zawartości i kodowanie jest wysoce ironiczne, ponieważ bez znajomości tych rzeczy nie można przeanalizować pliku w celu uzyskania wartości metatagu.

Nie, to nie jest prawda. Przeglądarka zaczyna analizować plik jako domyślne kodowanie przeglądarki, UTF-8 lub ISO-8859-1. Ponieważ US-ASCII jest podzbiorem zarówno ISO-8859-1, jak i UTF-8, przeglądarka może dobrze odczytać tak czy inaczej ... tak samo. Gdy przeglądarka napotka metatag, jeśli kodowanie jest inne niż to, z którego już korzysta przeglądarka, przeglądarka ponownie ładuje stronę w określonym kodowaniu. Właśnie dlatego umieściliśmy meta charset tag u góry, tuż za tagiem head, zanim cokolwiek innego, nawet tytuł. W ten sposób możesz używać znaków UTF-8 w swoim tytule.

Musisz zapisać swoje pliki w kodowaniu UTF-8 bez BOM

To nie jest do końca prawda. Jeśli masz w dokumencie tylko znaki US-ASCII, możesz zapisać go jako US-ASCII i służyć jako UTF-8, ponieważ jest to podzbiór. Ale jeśli są znaki Unicode, masz rację, musisz zapisać jako UTF-8 bez BOM.

Jeśli chcesz mieć dobry edytor tekstu, który zapisze twoje pliki w UTF-8, polecam Notepad ++.

Na komputerze Mac użyj Bare Bones TextWrangler (bezpłatny) z Mac App Store lub Bare Bones BBEdit, który jest w Mac App Store za 39,99 USD ... bardzo tanie za tak świetne narzędzie. W obu aplikacjach na dole okna dokumentu znajduje się menu, w którym określasz kodowanie dokumentu i możesz łatwo wybrać „UTF-8 bez BOM”. I oczywiście możesz ustawić to jako domyślne dla nowych dokumentów w Preferencjach.

Ale jeśli Twój serwer obsługuje kodowanie w nagłówku HTTP, co jest zalecane, oba [metatagi] są niepotrzebne.

To jest niepoprawne Należy oczywiście ustawić kodowanie w nagłówku HTTP, ale należy również ustawić go w atrybucie meta charset, aby użytkownik mógł zapisać stronę poza przeglądarką w pamięci lokalnej, a następnie otworzyć ponownie później, w takim przypadku jedynym wskazaniem kodowania, które będzie obecne, jest atrybut meta charset. Powinieneś również ustawić znacznik podstawowy z tego samego powodu ... na serwerze znacznik podstawowy jest niepotrzebny, ale po otwarciu z pamięci lokalnej znacznik podstawowy umożliwia działanie strony tak, jakby znajdowała się na serwerze, ze wszystkimi zasoby w miejscu i tak dalej, brak zepsutych linków.

AddDefaultCharset UTF-8

Lub możesz po prostu zmienić kodowanie określonych typów plików, tak jak to:

AddType text/html;charset=utf-8 html

Wskazówka dotycząca obsługi plików UTF-8 i Latin-1 (ISO-8859-1) polega na nadaniu plikom UTF-8 rozszerzenia „tekstowego”, a plików Latin-1 „txt”.

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

Na koniec rozważ zapisanie dokumentów z zakończeniami linii uniksowej, a nie ze starszymi wersjami DOS lub (klasycznymi) zakończeniami linii Mac, które nie pomagają i mogą boleć, szczególnie w miarę, jak coraz bardziej oddalamy się od tych starszych systemów. Dokument HTML z prawidłowym kodowaniem HTML5, UTF-8 i zakończeniami linii uniksowych to dobrze wykonane zadanie. Możesz udostępniać i edytować oraz przechowywać i czytać oraz odzyskiwać i polegać na tym dokumencie w wielu kontekstach. To lingua franca. To jest cyfrowy papier.


20
„Jeśli w dokumencie masz tylko znaki ISO-8859-1, możesz zapisać go jako ISO-8859-1 i służyć jako UTF-8, ponieważ jest to podzbiór” - niepoprawny. Byłoby poprawne, gdyby zmienić „ISO-8859-1” na „US-ASCII”. US-ASCII jest kompatybilny z UTF-8, ponieważ jest podzbiorem, ISO-8859-1 nie. Aby przekonwertować ISO-8859-1 (zawierający znaki spoza ASCII) na UTF-8, należy zakodować znaki spoza ASCII. Punkty kodowe dla ISO-8859-1 istnieją w Unicode, ale UTF-8 koduje te poza US-ASCII inaczej niż ISO-8859-1.
thomasrutter

2
Twoja opinia na temat encji HTML jest dobra. W przeszłości używałem bytów tylko do stwierdzenia, że ​​zostały one przekonwertowane na swoje znaki UTF-8 po zapisaniu w różnych systemach i / lub otwarciu w różnych edytorach. Warto jednak zauważyć, że spacje nierozdzielające (& nbsp;) mogą dawać mylące wyniki, ponieważ zazwyczaj nie widać ich w edytorze, dlatego najlepiej jest zachować je jako czystość (z mojego doświadczenia).
squidbe

"You should also set a base tag..."powinny pochodzić z opisanych tutaj ostrzeżeń .
Mafuba,

Innym powodem, dla którego wolisz jednostki HTML jest to, że używasz czegoś takiego jak jony . Wolę zobaczyć &#xf101;niż domyślny glif lub jakąś dziwną postać, której nie rozpoznaję.
Daniel Lubarov

30

<meta charset="utf-8"> został wprowadzony z / dla HTML5.

Jak wspomniano w dokumentacji, oba są ważne. Jednak <meta charset="utf-8">dotyczy tylko HTML5 (i łatwiejsze do pisania / zapamiętywania).

W odpowiednim czasie stary styl zostanie wkrótce uznany za przestarzały . Trzymałbym się nowego <meta charset="utf-8">.

Jest tylko jeden sposób, ale w górę. W przypadku techników to wycofywanie starego (naprawdę, NAPRAWDĘ szybko)

Dokumentacja: HTML meta charset Atrybut — W3Schools



18

Chociaż nie kwestionuję innych odpowiedzi, uważam, że warto wspomnieć o następujących kwestiach.

  1. Długi" (http-equivNotacja ) i „krótka” są równe, w zależności od tego, co nastąpi pierwsze, wygrywa;
  2. Nagłówki serwera WWW zastąpią wszystkie <meta> tagi;
  3. BOM (znak kolejności bajtów) zastąpi wszystko , aw wielu przypadkach wpłynie na HTML 4 (i prawdopodobnie także inne rzeczy);
  4. Jeśli nie zadeklarujesz żadnego kodowania, prawdopodobnie otrzymasz tekst w „kodowaniu zastępczym”, który jest zdefiniowany w przeglądarce. Ani w Firefoksie, ani w Chrome to utf-8;
  5. W przypadku braku innych wskazówek przeglądarka podejmie próbę odczytania twojego dokumentu tak, jakby był w ASCII, aby uzyskać kodowanie, więc nie możesz używać żadnych dziwnych kodowań (choć powinna to zrobić utf-16 z BOM);
  6. Choć specyfikacje mówią, że deklaracja kodowania musi zawierać się w pierwszych 512 bajtach dokumentu, większość przeglądarek spróbuje odczytać więcej.

Możesz przetestować, uruchamiając 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 4500i wskazując przeglądarkę na localhost:4500. (Oczywiście chcesz zmienić lub usunąć części. Część BOM jest \xef\xbb\xbf. Uważaj na kodowanie swojej powłoki.)

Pamiętaj, że bardzo ważne jest jawne zadeklarowanie kodowania. Zgadywanie przez przeglądarki może prowadzić do problemów z bezpieczeństwem.


1
Dobre punkty, ale czy możesz szczegółowo opisać, do których kwestii bezpieczeństwa się odnosisz?
Armfoot

1
Długa notacja nie powinna zastępować krótkiej - po prostu pierwsza z dokumentu powinna wygrać.
gsnedders,

1
@Armfoot W przeszłości występowały problemy z UTF-7tym, co pamiętam. Również wąchanie w Internecie jest ogólnie złe, np. Gdy przesyłasz obraz coś, co jest wąchane jako treść skryptu.
phk

@gsnedders przetestowane w Chrome i Firefox, masz rację. odpowiednio zredagował odpowiedź. Armfoot: chodziło o jakieś 7-bitowe kodowanie, nie pamiętam dokładnie.
wiewiórka

1
@CraigMcQueen całkiem pewny, że w przypadku powrotu do trybu rezerwowego przeglądarki (w 2018 r.) Domyślnie wybrano opcję zachodnioeuropejską w Europie Zachodniej, więc wyobrażam sobie, że domyślnie stosuje się kodowanie pre-Unicode dominujące w każdym regionie. Użytkownicy mogą ustawić tryb zastępczy na utf-8, ale to po prostu ujawnia wszystkie gówniane kodowanie, które tysiące witryn wciąż używają jako błędnych znaków ascii o wysokim bajcie, więc nadal nie jest to powszechne. Więcej szkoda. Nie widzę, jak to się zmieni bez niewielkiego przymusu ze strony producentów przeglądarek, i nie są zainteresowani łamaniem starszych treści.
brennanyoung

13

Użyj <meta charset="utf-8" />dla przeglądarek internetowych podczas korzystania z HTML5.

Użyj <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />gdy używasz HTML4 lub XHTML, lub do przestarzałych parserów domen, jak DOMDocumentw php 5.3



1

Aby osadzić podpis na wiadomości e-mail, użyłbym długiej wersji:

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

Powodem jest to, że niewiele czytników e-mail korzysta z HTML5, więc zawsze lepiej używać starych stylów HTML. W rzeczywistości lepiej jest również używać tabel niż divs + css.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.