Frage meta http-equiv="Content-Type"

  • Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

semtec

Neues Mitglied
6 Mai 2020
7
0
1
Hallo!

Kann mir jemand erklären wie der html meta tag

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


oder

<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1"/>


funktioniert oder funktionieren soll? Denn die Browser Firefox und Opera funktionieren nicht so wie ich es erwarte.

Im Detail:

Rufe ich die Seiten direkt auf, dann stehen die obigen html header im Quelltext und die http-header sind Content-Type: text/html. Wohlgemerkt ohne Charset-Angabe, aber die Seiten werden bei mir korrekt angezeigt.

Schreibe ich nun ein PHP-Skript und hole die Seiten mit curl und gebe sie dann mit 'echo' wieder aus, werden die Sonderzeichen nicht korrekt angezeigt! (Das PHP-Skript wird von XAMPP ausgeführt, wenn ich localhost aufrufe.) Erst wenn ich im http-header auch den korrekten charset ( header("Content-Type: text/html; charset=iso-8859-1"); ) angebe, werden die Sonderzeichen auch über mein Skript korrekt angezeigt. Das einfache durchreichen der original Header reicht nicht aus.

Nun meine Fragen:

1) Wofür sind die html header da, wenn die Browser sie bei fehlender Angabe im http header nicht nutzen?

2) Warum stellen die Browser die Sonderzeichen bei Direktaufruf korrekt dar und über mein Proxyskript aufgerufen, nicht?

3) Welche Kriterien gibt es überhaupt und wie ist deren Priorität, nach denen ein Browser entscheidet wie er die Seiten anzeigt?

Vielen Dank!
 

semtec

Neues Mitglied
6 Mai 2020
7
0
1
werde ich hier ignoriert oder weiß wirklich niemand etwas erhellendes beizutragen?
 

threadi

Moderator
Teammitglied
Moderator
20 Oktober 2006
15.371
302
83
Leipzig
www.comedy-news.de
Sobald der HTTP-Header gesetzt ist ignorieren Browser die Angabe im HTML-Code. Im HTML-Code wiederum gibt man, wenn man den Content-type nicht im HTTP-Header hat und HTML5 verwendet, den Charset wie hier beschrieben an:

Die HTML-Angaben gibt es eigentlich nur für die Fälle in denen man eine HTML-Datei lokal und ohne Webserver bearbeitet damit der Browser auch ohne HTTP-Header darüber informiert wird.
 

semtec

Neues Mitglied
6 Mai 2020
7
0
1
Vielen Dank für Deine Antwort.

Wenn der http-header zwar gesetzt ist aber kein charset angegeben ist ...
Content-Type: text/html
... dann muss der Browser ja auch eine Entscheidung treffen. Wie kann es da zu unterschiedlichen Anzeigen kommen, je nachdem ob ich die Seite direkt oder über curl aufrufe? Die Entscheidung kann da ja offensichtlich nicht anhand des http-header getroffen worden sein und auch nicht anhand des html header. Es kann auch kein Rückfall auf einen Default-Wert sein, denn dann müssten die Anzeigen ja auch gleich sein.
 

threadi

Moderator
Teammitglied
Moderator
20 Oktober 2006
15.371
302
83
Leipzig
www.comedy-news.de
Ah, die waren als solche gar nicht erkennbar.

Beide Seiten setzen als Content-type text/html per HTTP-Header und geben den Zeichensatz einzig im HTML-Code an. Die Seite https://www.henningvoosen.de/ hat dabei ein echtes Problem mit dem HTML-Code an sich - der ist so kaputt, dass jeder Browser tatsächlich raten muss wie er die Seite darstellen soll. Das trifft auch auf den Zeichensatz zu.

curl arbeitet nur mit dem HTTP-Header und interpretiert keine Angabe im HTML-Code.

Außerdem: aktuelle Empfehlung ist es den Content-type wie auch Zeichensatz im HTTP-Header anzugeben und mit utf8 zu arbeiten. Keine der beiden Seiten erfüllt das.
 

semtec

Neues Mitglied
6 Mai 2020
7
0
1
Ja danke, nur sind das nicht meine Seiten, ich habe keinerlei Einfluß darauf. Und sorry aber ich habe das Gefühl unverstanden zu sein.
Ich erwarte nicht das curl irgendetwas interpretiert, curl reicht nur die Seite weiter an meinen browser und die beiden getesten browser zeigen mir ein und die selbe Seite unterschiedlich an, je nachdem ob sie mein Skript auf localhost aufrufen oder die Seiten direkt holen, obwohl sie die gleichen http-header bekommen. Der einzige unterschied ist, einmal ruft der Browser die original Webseite auf und das anderemal ruft er localhost auf.