nicht angemeldet
MudGuard
dedlfix
MudGuard
dedlfix
dedlfix
dedlfix
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Wie kann ich dieses Problem lösen?
Vielen Dank, Jeannie
Hi,
Wie kann ich dieses Problem lösen?
den Webserver entsprechend konfigurieren.
Ersatzweise im Script einen Content-Type-Header mit Encoding-Angabe ausgeben (natürlich bevor irgendein Seiteninhalt ausgegeben wird)
cu,
Andreas a/k/a MudGuard
Tach!
Ersatzweise im Script einen Content-Type-Header mit Encoding-Angabe ausgeben (natürlich bevor irgendein Seiteninhalt ausgegeben wird)
Vor oder nach Content ist nicht weiter relevant, es muss nur innerhalb der ersten 1024 Bytes stehen. Zudem gibt es heutzutage
<meta charset="UTF-8">
um sich nicht mehr mit
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
herumschlagen zu müssen. Aber beides wird vielleicht nicht zur Beseitigung der Meldung führen, da wird wohl nur eine entsprechend Konfiguration im Server helfen. Welche? Das ist abhängig vom Server und teilweise auch von dem, was da bereits konfiguriert ist.
dedlfix.
Hi,
Ersatzweise im Script einen Content-Type-Header mit Encoding-Angabe ausgeben (natürlich bevor irgendein Seiteninhalt ausgegeben wird)
Vor oder nach Content ist nicht weiter relevant, es muss nur innerhalb der ersten 1024 Bytes stehen. Zudem gibt es heutzutage
Laut Betreff geht es um den HTTP-Header, nicht um das head-Element im HTML. Und HTTP-Header können nur vor dem Content losgeschickt werden.
cu,
Andreas a/k/a MudGuard
Tach!
Ersatzweise im Script einen Content-Type-Header mit Encoding-Angabe ausgeben (natürlich bevor irgendein Seiteninhalt ausgegeben wird)
Laut Betreff geht es um den HTTP-Header, nicht um das head-Element im HTML. Und HTTP-Header können nur vor dem Content losgeschickt werden.
Achja, du meintest im PHP- / serverseitigen Script. Das hatte ich falsch gedeutet.
dedlfix.
Die erste Frage ist ja auch, wer diese Meldung ausgibt.
Wenn das nicht klar ist, kann jede Antwort nur eine Vermutung sein!
Tach!
Die erste Frage ist ja auch, wer diese Meldung ausgibt.
Wenn das nicht klar ist, kann jede Antwort nur eine Vermutung sein!
Anhand der anderen Fragen des OP liegt die Vermutung recht nahe, dass es sich um eine Art Validator handelt. Zudem ist es nicht ungewöhnlich, dass die charset-Angabe im Content-Type-HTTP-Header fehlt. Sie ist aber einigermaßen wichtig, auch wenn es Ersatz in Form von In-Dokument-Angaben gibt. Es ist aber technisch gesehen besser, wenn man vor dem Parsen des Dokuments die Kodierung weiß, dann muss man nicht nochmal neu ansetzen, nachdem man das Dokument zu lesen angefangen hat.
dedlfix.
Die erste Frage ist ja auch, wer diese Meldung ausgibt.
Wenn das nicht klar ist, kann jede Antwort nur eine Vermutung sein!
Anhand der anderen Fragen des OP liegt die Vermutung recht nahe, dass es sich um eine Art Validator handelt. Zudem ist es nicht ungewöhnlich, dass die charset-Angabe im Content-Type-HTTP-Header fehlt. Sie ist aber einigermaßen wichtig, auch wenn es Ersatz in Form von In-Dokument-Angaben gibt. Es ist aber technisch gesehen besser, wenn man vor dem Parsen des Dokuments die Kodierung weiß, dann muss man nicht nochmal neu ansetzen, nachdem man das Dokument zu lesen angefangen hat.
Vermuten kann man, ja. Man muss es jedoch wissen wenn man das Problem nachzustellen gedenkt! Dann wäre auch noch die Frage, auf was sich die Angabe des fehlenden Encoding bezieht.
MfG
Tach!
Vermuten kann man, ja. Man muss es jedoch wissen wenn man das Problem nachzustellen gedenkt! Dann wäre auch noch die Frage, auf was sich die Angabe des fehlenden Encoding bezieht.
Siehe Thema (← dein Lieblingsspruch), es handelt sich um einen HTTP-Header. Wo treten diese auf und wieviele Angaben zur Zeichenkodierung gibt es in den HTTP-Headern? Für mich ist das ziemlich eindeutig, was da für ein Problem angekreidet wird. (Auch unabhängig davon, dass ich Mudgards Antwort zuerst fehlgedeutet habe.)
dedlfix.
Vermuten kann man, ja. Man muss es jedoch wissen wenn man das Problem nachzustellen gedenkt! Dann wäre auch noch die Frage, auf was sich die Angabe des fehlenden Encoding bezieht.
Siehe Thema (← dein Lieblingsspruch), es handelt sich um einen HTTP-Header.
Ja sicher gehts um einen HTTP Header, das steht ja im Betreff. Ist nur ein bischen wenig für eine fachmännische Problemlösung!
Wer hier im Forum Fragen stellt, erwartet Fachkompetenz!
MfG
@@pl
Wer hier im Forum Fragen stellt, erwartet Fachkompetenz!
Du hast deine Fachkompetenz bezüglich Umgangs mit Zeichencodierungen ja hier im Forum schon desöfteren unter Beweis gestellt. 🤣 ROTFL.
LLAP 🖖
es gibt auch hier im Forum Fachkräfte die denken daß sie umso kompetenter erscheinen je überzeugender sie auftreten.
Diese Unsitte ist leider auch allgemein stark verbreitet.
MfG
Die erste Frage ist ja auch, wer diese Meldung ausgibt.
Wenn das nicht klar ist, kann jede Antwort nur eine Vermutung sein!
Anhand der anderen Fragen des OP liegt die Vermutung recht nahe, dass es sich um eine Art Validator handelt.
Fragt sich nur, welcher. Der von w3org jedenfalls meldet sowas nicht sondern allenfalls:
The character encoding was not declared
und bei diesem Test bei dem die Seite ohne Angabe des Charset im HTTP Header gesendet wurde, gab es nicht einmal einen <head>-Bereich.
MfG
@@dedlfix
charset-Angabe im Content-Type-HTTP-Header […] ist aber einigermaßen wichtig, auch wenn es Ersatz in Form von In-Dokument-Angaben gibt. Es ist aber technisch gesehen besser, wenn man vor dem Parsen des Dokuments die Kodierung weiß, dann muss man nicht nochmal neu ansetzen, nachdem man das Dokument zu lesen angefangen hat.
Es gibt aber auch Fälle, wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.
LLAP 🖖
Es gibt aber auch Fälle, wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.
Deine dortige "Begründung" würde höchstens zutreffen für den Fall, daß
Natürlich macht dieser Zusammenhang keinen Sinn und es stellt den Sinn einer Charsetangabe im Header auch nicht in Frage. Infolgedessen gibt es auch keine Fälle, in denen eine Charsetangabe im Header unsinnig wäre.
Bedenke auch, daß es nicht nur Content-Types: text/html gibt. Bei einem Content-Type text/plain z.b. gibt es gar keine andere Möglichkeit dem Browser die Kodierung mitzuteilen als eben im HTTP Header.
MfG
@@pl
Es gibt aber auch Fälle, wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.
Deine dortige "Begründung" würde höchstens zutreffen für den Fall, daß
- der Content-Type+Charset Header generell gesetzt
- es während dieser Zeit Dokumente gibt auf denen die im Header deklarierte Chrsetangabe nicht zutrifft.
Genau das war dort ja der Fall. Was also ist dein Punkt?
BTW, wenn du Text mit Leerzeichen einrückst, wird das als Code markiert (nachzulesen in der Hilfe). Ich hab die Formatierung deines Postings mal berichtigt.
Natürlich macht dieser Zusammenhang keinen Sinn und es stellt den Sinn einer Charsetangabe im Header auch nicht in Frage. Infolgedessen gibt es auch keine Fälle, in denen eine Charsetangabe im Header unsinnig wäre.
Deine logischen Schlüsse sind immer wieder beeindruckend. Nicht.
Bedenke auch, daß es nicht nur Content-Types: text/html gibt. Bei einem Content-Type text/plain z.b. gibt es gar keine andere Möglichkeit dem Browser die Kodierung mitzuteilen als eben im HTTP Header.
Auch darüber solltest du nochmal nachdenken.
LLAP 🖖
Eine Charsetangabe zum Content-Type text mach immer Sinn. Daran hält sich sogar XMLHttpRequest:
var xhr = new XMLHttpRequest();
xhr.open('POST','%url%');
xhr.send(JSON.stringify([1,2,3]));
und generiert spontan einen Requestheader Content-Type: text/plain;charset=UTF-8
Der Sinn ergibt sich aus der Tatsache, daß es auf Byteebene (Transport) keine Kodierung gibt, denn diese ist grundsätzlich immer eine Sache der Vereinbarung!
MfG
@@pl
Eine Charsetangabe zum Content-Type
textmach immer Sinn.
Das mag ja sein. Das ändert aber nichts daran, dass deine Aussage „Bei einem Content-Type text/plain z.b. gibt es gar keine andere Möglichkeit dem Browser die Kodierung mitzuteilen als eben im HTTP Header“ falsch ist.
LLAP 🖖
auch ein BOM ist eine Sache der Vereinbarung. D.h., der Empfänger muss wissen, ob er ein BOM zu lesen hat und wenn ja, wieviele Bytes!
Die Logik dahinter ist jedoch dieselbe und läuft stets auf eine Vereinbarung Content-Type+Charset hinaus. Beim Content-Type text/html ist es möglich auf den Charsetparameter zu verzichten, weil dieser Content-Type die Möglichkeit vorsieht die Kodierung im Dokument selbst zu deklarieren.
Bei einem Content-Type text/plain (ohne Charsetangabe) hingegen wird ein Browser möglicherweise versuchen, anhand einer etwa vorhandenen BOM die Kodierung zu ermitteln.
MfG
PS: Ich schrieb möglicherweise. Mein FF jedenfalls tut es nicht. Dh. er kann, obwohl ein gültiges BOM vorhanden ist, die Kodierung gar nicht feststellen!
D.h., daß man nicht davon ausgehen kann, daß ein HTTP Client bei text/plain die Kodierung am Inhalt erkennt!
@@pl
auch ein BOM ist eine Sache der Vereinbarung. D.h., der Empfänger muss wissen, ob er ein BOM zu lesen hat und wenn ja, wieviele Bytes!
??
Wenn der Empfänger im Bytestream EF BB BF liest, dann ist es ein BOM.
Wenn der Empfänger im Bytestream FE FF liest, dann ist es ein BOM.
Wenn der Empfänger im Bytestream FF FE liest, dann ist es ein BOM.
Beim Content-Type text/html ist es möglich auf den Charsetparameter zu verzichten, weil dieser Content-Type die Möglichkeit vorsieht die Kodierung im Dokument selbst zu deklarieren.
Auf zwei Arten:
charset="…"Bei einem Content-Type text/plain (ohne Charsetangabe) hingegen wird ein Browser möglicherweise versuchen, anhand einer etwa vorhandenen BOM die Kodierung zu ermitteln.
Was eben auch eine Deklaration der Zeichencodierung im Dokument selbst ist.
LLAP 🖖
nun, der Unterschied sollte klar sein. Im Fall text/html wird ein Browser anhand der 1. Zeile den Doctype feststellen, damit die HTML-Version und anhand derer das für die Zeichenkodierung zuständige HTML-Element worin schließlich die Angabe der Kodierung zu finden ist.
Ergo genügt die Angabe text/hml.
> Wenn der Empfänger im Bytestream EF BB BF liest, dann ist es ein BOM.
> Wenn der Empfänger im Bytestream FE FF liest, dann ist es ein BOM.
> Wenn der Empfänger im Bytestream FF FE liest, dann ist es ein BOM.
Nein ist es nicht. Aber wahrscheinlich suchst Du nur Streit. Lass es einfach!
@@pl
Im Fall text/html wird ein Browser anhand der 1. Zeile den Doctype feststellen, damit die HTML-Version und anhand derer das für die Zeichenkodierung zuständige HTML-Element worin schließlich die Angabe der Kodierung zu finden ist.
Du irrst.
Für die Angabe der Zeichencodierung ist kein HTML-Element zuständig, sondern allein die Zeichenkette charset="…". (Wobei … für eine gültigen Zeichencodierungsbezeichner steht und statt " auch ' oder gar nichts stehen kann.)
Die HTML-Version hat damit gar nichts zu tun. Eben deshalb konnte man ja <meta charset="…"> einführen, weil auch Prä-HTML5-Parser das auswerten konnten.
Das meta-Element hat den Zweck, die Angabe regelkonform in HTML-Syntax unterzubringen.
Moment mal, dann sollte eigentlich auch <html charset="…"> als Zeichencodierungsangabe funktionieren.
Oder sogar auch <!-- charset="…" -->? Da müsste ich aber erstmal nachlesen, ob der Parser auch in Kommentaren sucht.
Aber wahrscheinlich suchst Du nur Streit. Lass es einfach!
Du gibst mir mal wieder recht. Schade eigentlich.
LLAP 🖖
hallo
@@pl
auch ein BOM ist eine Sache der Vereinbarung. D.h., der Empfänger muss wissen, ob er ein BOM zu lesen hat und wenn ja, wieviele Bytes!
??
Wenn der Empfänger im Bytestream EF BB BF liest, dann ist es ein BOM.
Wenn der Empfänger im Bytestream FE FF liest, dann ist es ein BOM.
Wenn der Empfänger im Bytestream FF FE liest, dann ist es ein BOM.
Am anfang des Bytestroms. Und das ist nur der Fall, weil der Empfänger zu einer Auflösung nach U+FFFE gelangt.
Es gibt im übrigen noch sehr viel mehr Muster.
@@beatovich
Wenn der Empfänger im Bytestream EF BB BF liest, dann ist es ein BOM.
Wenn der Empfänger im Bytestream FE FF liest, dann ist es ein BOM.
Wenn der Empfänger im Bytestream FF FE liest, dann ist es ein BOM.Am anfang des Bytestroms.
Ja. Ich hatte schon im Kopf, das nach dem Frühstück noch zu berichtigen. Du warst schneller.
Und das ist nur der Fall, weil der Empfänger zu einer Auflösung nach U+FFFE gelangt.
??
Es gibt im übrigen noch sehr viel mehr Muster.
Ja. Ich wollte mich hier auf die relevante und die nicht gänzlich irrelevante Unicode-Codierung beschränken.
LLAP 🖖
hallo
Wenn der Empfänger im Bytestream EF BB BF liest, dann ist es ein BOM.
Es sind 3 Zeichen: 
Ob diese 3 Zeichen ein BOM sein sollen ist eine Frage der Vereinbarung!
Am anfang des Bytestroms. Und das ist nur der Fall, weil der Empfänger zu einer Auflösung nach U+FFFE gelangt.
Unicode non-character 0xfffe is illegal for interchange sagt eine ältere Perlversion.
Man könnte das ignorieren und versuchen diesen Codepoint in Oktetten umzurechnen. Das ergibt mit Perl v5.16.3 dann: 239 191 190 (Oktetten dezimal) und das sind auch wieder Zeichen ￾
MfG
hallo
auch ein BOM ist eine Sache der Vereinbarung. D.h., der Empfänger muss wissen, ob er ein BOM zu lesen hat und wenn ja, wieviele Bytes!
Eine Verienbarung ist eine Einigung zwischen mehreren Partnern wobei alle frei sein müssen, zwischen mehreren Optionen sich zu entscheiden.
Ich wüsste nicht, wie ein CGI Prozess frei ist, eine shebang Zeile mit oder ohne BOM zu lesen.
Die Logik dahinter ist jedoch dieselbe und läuft stets auf eine Vereinbarung Content-Type+Charset hinaus. Beim Content-Type text/html ist es möglich auf den Charsetparameter zu verzichten, weil dieser Content-Type die Möglichkeit vorsieht die Kodierung im Dokument selbst zu deklarieren.
...so wie auch andere Fileformate Informationen enthalten, die für den Parser relevant sind.
Ich hatte im übrigen da mal eine Beobachtung:
https://forum.selfhtml.org/self/2018/aug/20/msie-11-ein-paar-beobachtungen/1729448#m1729448
Betrifft MSIE 10 xhr-Zugriff auf Datei ohne BOM.
Es gibt für HTTP einen Default Enctype: application/x-www-form-urlencoded
und der ist von der Zeichenkodierung unabhängig weil die darauf aufsetzende Prozentkodierung bytesemantisch arbeitet.
...so wie auch andere Fileformate Informationen enthalten, die für den Parser relevant sind.
Nein. Relevant für einen Parser ist einzig der Content-Type! Und da ein Parser bytesemantisch arbeitet ist die Zeichenkodierung völlig nebensächlich.
MfG
hallo
Ich wüsste nicht, wie ein CGI Prozess frei ist, eine shebang Zeile mit oder ohne BOM zu lesen.
Interessanter Gedanke. Abstrakt gesehen sind nämlich BOM als auch Shebang unter sog. Magic Numbers einzuordnen. Und natürlich kommt Müll dabei raus wenn sich Magic Numbers unterschiedlicher Zweckbestimmung in die Quere kommen.
BOM, Browser und XHR.. da kommt Freude auf am Programmiertisch. Mach Dir einen schönen Tag damit 😉
hallo
Es gibt aber auch Fälle, wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.
Warum sollte ich bei HTML-Dokumenten überhaupt einen http-header ausgeben?
hallo
Warum sollte ich bei HTML-Dokumenten überhaupt einen http-header ausgeben?
Interessante Frage! Sie geht, was die Problemstellung betrifft, in die richtige Richtung! Mir jedenfalls ist noch kein Drucker untergekommen, der sich über einen fehlenden Header beim Ausdrucken eines HTML-Dokuments beschwerd hätte.
Und wenn Du Deine HTML-Dokumente per DHL versendest ist das sicher ähnlich. Welche Instanz also vermeldet denn sowas: The character encoding is not specified in the HTTP header
???
hallo
Es gibt aber auch Fälle, wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.
Warum sollte ich bei HTML-Dokumenten überhaupt einen http-header ausgeben?
Die Frage ist berechtigt. Denn es gibt ja auch HTTP-Trailer!
MfG
Wie kann ich dieses Problem lösen?
Wer behauptet denn daß da wo ein Problem ist? Ich würde das gerne mal nachstellen.
MfG