Jak przekazać przeglądarce kodowanie znaków w witrynie HTML bez względu na nagłówek typu zawartości serwera?

9

Mam stronę HTML, która poprawnie (kodowanie fizycznego na dysku pasuje do niego) informuje o jej typie zawartości :

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="Content-Type" content=
    "text/html; charset=utf-8">
    <title> ...

Otwieranie pliku z dysku w przeglądarce (Google Chrome, Firefox) działa dobrze.

Żądając go przez HTTP, serwer internetowy wysyła inny nagłówek Content-Type:

$ curl -I http://example.com/file.html
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 10:57:13 GMT
...
Content-Type: text/html; charset=ISO-8859-1

(patrz ostatni wiersz). Przeglądarka używa następnie ISO-8859-1, aby wyświetlić niepożądany wynik.

Czy istnieje wspólny sposób na przesłonięcie nagłówków serwera wysyłanych do przeglądarki z poziomu dokumentu HTML?

— hakre
źródło

6

„Czy istnieje wspólny sposób na przesłonięcie nagłówków serwera wysyłanych do przeglądarki z poziomu dokumentu HTML?”

AFAIK nie, robisz to, co możesz już zrobić. Zdefiniowany zestaw znaków za pomocą nagłówka przebija twoją definicję w znaczniku META.

Jeśli masz dostęp do serwera, np. Apache, konfiguruje go ta instrukcja (patrz wiersze komentarza):

# Read the documentation before enabling AddDefaultCharset.
# In general, it is only a good idea if you know that all your files
# have this encoding. It will override any encoding given in the files
# in meta http-equiv or xml encoding tags.

#AddDefaultCharset UTF-8

[Aktualizacja]

Po drugie komentarz w3d tutaj znajdziesz kilka sposobów na zmianę zestawu znaków za pomocą dyrektyw htaccess dla serwera Apache.

— początkowo
źródło

2

+1 nagłówki HTTP zastępują metatagi HTML. Jeśli @hakre ma dostęp do strony serwera, wówczas mogą również zastąpić nagłówek Content-Type dla poszczególnych stron.

— MrWhite,

3

Tak, oto odniesienie normatywne, które określa, że nagłówki HTTP przebijają metatagi: w3.org/TR/REC-html40/charset.html#h-5.2.2

— Jukka K. Korpela,

Dziękuję za odpowiedź. @Korpela: Tak, miałem to w pamięci ze specyfikacjami HTML. Jest dokładnie na odwrót, tak jak potrzebuję :(.

— hakre

Jeśli chodzi o .htaccess (przepraszam, może to powinno być nowe pytanie), czy można również usunąć ;charset=...nagłówek http. Witryna działa bardzo dobrze Content-Type: text/html, różne pliki mają różne kodowania na serwerze. (Obawiam się, że to również nie jest możliwe, ponieważ myślę, że szukałem tego kilka tygodni temu, ale wynik nie był do końca ostateczny). Na wypadek, gdybyś mógł rzucić nieco światła przed siebie.

— hakre

@hakre Jeśli dyrektywa ForceType Apache działa dla Ciebie, umieść ją w kontenerze <Files> i osobno nazwij pliki lub niektóre katalogi. Po prostu zostaw część „; charset =” po typie MIME, to powinno to zrobić.

— początkowo

3

Powinieneś ustawić coś takiego w swoim katalogu głównym .htaccess

<FilesMatch "\.(htm|html|xhtml|xml|php)$">
    AddDefaultCharset utf-8
</FilesMatch>

— PatomaS
źródło

3

Nie, nie jest to możliwe z poziomu HTML. Nagłówek odpowiedzi serwerów ma pierwszeństwo przed metatagiem dokumentu. Jak określono w 5.2.2 Określanie kodowania znaków - Specyfikacja HTML 4.01 :

Podsumowując, zgodne programy użytkownika muszą przestrzegać następujących priorytetów podczas określania kodowania znaków dokumentu (od najwyższego priorytetu do najniższego):

Parametr „charset” HTTP w polu „Content-Type”.

Deklaracja META z „http-equiv” ustawioną na „Content-Type” i wartością ustawioną dla „charset”.

Atrybut charset ustawiony na elemencie, który wyznacza zasób zewnętrzny.

Wymaga to więc konfiguracji po stronie serwera. Jednak w miarę kontynuowania rozdziału:

Programy klienckie mogą zapewniać mechanizm, który pozwala użytkownikom zastępować nieprawidłowe informacje o „zestawie znaków”. Jeśli jednak klient użytkownika oferuje taki mechanizm, powinien oferować go tylko do przeglądania, a nie do edycji, aby uniknąć tworzenia stron internetowych oznaczonych niepoprawnym parametrem „charset”.

W moim przypadku nagłówek Content-Type serwera zawiera właściwy typ MIME, ale zły zestaw znaków .

Jak się okazało, moja konfiguracja Apache httpd ustawiła AddDefaultCharsetwłączenie, które dodawało ; charset=ISO-8859-1część. Umieszczenie w katalogu głównym stron internetowych .htaccessnastępującej linii:

AddDefaultCharset Off

informacje o zestawie znaków zostały usunięte:

$ curl -I http://example.com/file.html
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 15:07:52 GMT
...
Content-Type: text/html

(patrz ostatni wiersz, bez ; charset=...części). To w połączeniu z metatagiem HTML powoduje, że wspomniana heurystyka przeglądarki przejmuje zestaw znaków od metatagu. Strona internetowa jest poprawnie odkodowana.

Testowane z:

Google Chrome wer. 22.0.1229.94
Firefox v. 16.0.1
Wersja Lynx 2.8.7rel.1 (05 lipca 2009 r.)

Te trzy przeglądarki miały problemy z oryginalną konfiguracją i działają teraz (wszystkie na Fedorze 17).

Opera 12.02
Internet Explorer 6 (Win XP SP3)

Po pierwsze, nie miałem problemu. Obaj woleli UTF-8 od metatagu niż ustawienie ISO-8859-1 z serwera.

Netscape 2.01 Gold

Nie obsługuje UTF-8, dlatego zawsze wybiera Western (Latin1) bez względu na ustawienia serwera i metatag.

— hakre
źródło

1

Oprócz tego, co powiedziano tutaj, spróbuję użyć tego samego zestawu znaków na wszystkich stronach - najlepiej UTF-8(ale jeśli prawie wszystko jest iso-8859-1, użyj tego).

Aby szybko sprawdzić zestaw znaków pliku, możesz spróbować:

file --mime-type --mime-encoding {filename}

Aby sprawdzić zestaw znaków wszystkich plików w drzewie, możesz spróbować:

find . -type f -exec file --mime-type --mime-encoding '{}' \;

lub (wywoływanie filepolecenia tylko raz):

find . -type f -print | file --mime-type --mime-encoding -f-

Aby uzyskać podsumowanie, użyj -bopcji filepolecenia (aby pominąć nazwy plików) i potokuj wynik sort | uniq -c.

— Tobiasz
źródło