tag:forum.selfhtml.org,2005:/self The character encoding is not specified in the HTTP header – SELFHTML-Forum 2018-12-16T09:00:53Z https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738452#m1738452 jeannie61 2018-12-13T18:32:01Z 2018-12-13T18:32:38Z The character encoding is not specified in the HTTP header <p>Wie kann ich dieses Problem lösen?</p> <p>Vielen Dank, Jeannie</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738453#m1738453 MudGuard http://www.andreas-waechter.de/ 2018-12-13T18:51:42Z 2018-12-13T18:51:42Z The character encoding is not specified in the HTTP header <p>Hi,</p> <blockquote> <p>Wie kann ich dieses Problem lösen?</p> </blockquote> <p>den Webserver entsprechend konfigurieren.</p> <p>Ersatzweise im Script einen Content-Type-Header mit Encoding-Angabe ausgeben (natürlich bevor irgendein Seiteninhalt ausgegeben wird)</p> <p>cu,<br> Andreas a/k/a MudGuard</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738459#m1738459 pl 2018-12-13T21:00:07Z 2018-12-13T21:00:07Z The character encoding is not specified in the HTTP header <blockquote> <p>Wie kann ich dieses Problem lösen?</p> </blockquote> <p>Wer behauptet denn daß da wo ein Problem ist? Ich würde das gerne mal nachstellen.</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738482#m1738482 dedlfix 2018-12-14T06:09:15Z 2018-12-14T06:09:15Z The character encoding is not specified in the HTTP header <p>Tach!</p> <blockquote> <p>Ersatzweise im Script einen Content-Type-Header mit Encoding-Angabe ausgeben (natürlich bevor irgendein Seiteninhalt ausgegeben wird)</p> </blockquote> <p>Vor oder nach Content ist nicht weiter relevant, es muss nur innerhalb der ersten 1024 Bytes stehen. Zudem gibt es heutzutage</p> <pre><code class="block language-html"><span class="token tag"><span class="token tag"><span class="token punctuation"><</span>meta</span> <span class="token attr-name">charset</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>UTF-8<span class="token punctuation">"</span></span><span class="token punctuation">></span></span> </code></pre> <p>um sich nicht mehr mit</p> <pre><code class="block language-html"><span class="token tag"><span class="token tag"><span class="token punctuation"><</span>meta</span> <span class="token attr-name">http-equiv</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>Content-Type<span class="token punctuation">"</span></span> <span class="token attr-name">content</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>text/html;charset=UTF-8<span class="token punctuation">"</span></span><span class="token punctuation">></span></span> </code></pre> <p>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.</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738485#m1738485 MudGuard http://www.andreas-waechter.de/ 2018-12-14T07:02:33Z 2018-12-14T07:02:33Z The character encoding is not specified in the HTTP header <p>Hi,</p> <blockquote> <blockquote> <p>Ersatzweise im Script einen Content-Type-Header mit Encoding-Angabe ausgeben (natürlich bevor irgendein Seiteninhalt ausgegeben wird)</p> </blockquote> <p>Vor oder nach Content ist nicht weiter relevant, es muss nur innerhalb der ersten 1024 Bytes stehen. Zudem gibt es heutzutage</p> </blockquote> <p>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.</p> <p>cu,<br> Andreas a/k/a MudGuard</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738486#m1738486 dedlfix 2018-12-14T07:08:25Z 2018-12-14T07:08:25Z The character encoding is not specified in the HTTP header <p>Tach!</p> <blockquote> <blockquote> <blockquote> <p>Ersatzweise im Script einen Content-Type-Header mit Encoding-Angabe ausgeben (natürlich bevor irgendein Seiteninhalt ausgegeben wird)</p> </blockquote> </blockquote> <p>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.</p> </blockquote> <p>Achja, du meintest im PHP- / serverseitigen Script. Das hatte ich falsch gedeutet.</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738491#m1738491 pl 2018-12-14T07:52:40Z 2018-12-14T07:52:40Z The character encoding is not specified in the HTTP header <p>Die erste Frage ist ja auch, <a href="https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738459#m1738459" rel="noopener noreferrer">wer diese Meldung</a> ausgibt.</p> <p>Wenn das nicht klar ist, kann jede Antwort nur eine Vermutung sein!</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738493#m1738493 dedlfix 2018-12-14T08:05:44Z 2018-12-14T08:05:44Z The character encoding is not specified in the HTTP header <p>Tach!</p> <blockquote> <p>Die erste Frage ist ja auch, <a href="https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738459#m1738459" rel="noopener noreferrer">wer diese Meldung</a> ausgibt.</p> <p>Wenn das nicht klar ist, kann jede Antwort nur eine Vermutung sein!</p> </blockquote> <p>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.</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738495#m1738495 pl 2018-12-14T08:24:05Z 2018-12-14T08:24:05Z Deine Herangehensweise <p><a href="/users/27" class="mention registered-user" rel="noopener noreferrer">@dedlfix</a></p> <blockquote> <blockquote> <p>Die erste Frage ist ja auch, <a href="https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738459#m1738459" rel="noopener noreferrer">wer diese Meldung</a> ausgibt.</p> <p>Wenn das nicht klar ist, kann jede Antwort nur eine Vermutung sein!</p> </blockquote> <p>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.</p> </blockquote> <p>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.</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738544#m1738544 pl 2018-12-14T15:12:14Z 2018-12-14T15:12:14Z The character encoding is not specified in the HTTP header <p><a href="/users/27" class="mention registered-user" rel="noopener noreferrer">@dedlfix</a></p> <blockquote> <blockquote> <p>Die erste Frage ist ja auch, <a href="https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738459#m1738459" rel="noopener noreferrer">wer diese Meldung</a> ausgibt.</p> <p>Wenn das nicht klar ist, kann jede Antwort nur eine Vermutung sein!</p> </blockquote> <p>Anhand der anderen Fragen des OP liegt die Vermutung recht nahe, dass es sich um eine Art Validator handelt.</p> </blockquote> <p>Fragt sich nur, welcher. Der von w3org jedenfalls meldet sowas nicht sondern allenfalls:</p> <p><code>The character encoding was not declared</code></p> <p>und bei diesem Test bei dem die Seite ohne Angabe des Charset im HTTP Header gesendet wurde, gab es nicht einmal einen <head>-Bereich.</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738547#m1738547 Gunnar Bittersmann selfhtml@bittersmann.de https://bittersmann.de 2018-12-14T17:07:48Z 2018-12-14T17:07:48Z The character encoding is not specified in the HTTP header <p>@@dedlfix</p> <blockquote> <p>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.</p> </blockquote> <p>Es gibt aber auch Fälle, <a href="https://forum.selfhtml.org/self/2017/apr/14/kontaktformular-und-utf8-strich-unicode/1692157#m1692157" rel="noopener noreferrer">wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.</a></p> <p>LLAP </p> <div class="signature">-- <br> <em>„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“</em> —Kurt Weidemann </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738496#m1738496 dedlfix 2018-12-14T08:29:47Z 2018-12-14T08:29:47Z Deine Herangehensweise <p>Tach!</p> <blockquote> <p>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.</p> </blockquote> <p>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.)</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738497#m1738497 pl 2018-12-14T08:42:16Z 2018-12-14T08:42:16Z Deine Herangehensweise <p><a href="/users/27" class="mention registered-user" rel="noopener noreferrer">@dedlfix</a></p> <blockquote> <blockquote> <p>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.</p> </blockquote> <p>Siehe Thema (← dein Lieblingsspruch), es handelt sich um einen HTTP-Header.</p> </blockquote> <p>Ja sicher gehts um einen HTTP Header, das steht ja im Betreff. Ist nur ein bischen wenig für eine fachmännische Problemlösung!</p> <p>Wer hier im Forum Fragen stellt, erwartet Fachkompetenz!</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738548#m1738548 Gunnar Bittersmann selfhtml@bittersmann.de https://bittersmann.de 2018-12-14T17:10:44Z 2018-12-14T17:10:44Z Deine Herangehensweise <p>@@pl</p> <blockquote> <p>Wer hier im Forum Fragen stellt, erwartet Fachkompetenz!</p> </blockquote> <p>Du hast deine Fachkompetenz bezüglich Umgangs mit Zeichencodierungen ja hier im Forum schon desöfteren unter Beweis gestellt.  ROTFL.</p> <p>LLAP </p> <div class="signature">-- <br> <em>„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“</em> —Kurt Weidemann </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738554#m1738554 pl 2018-12-14T18:32:10Z 2018-12-14T19:15:59Z Content-Type: text/* <p><a href="/users/20" class="mention registered-user" rel="noopener noreferrer">@Gunnar Bittersmann</a></p> <blockquote> <p>Es gibt aber auch Fälle, <a href="https://forum.selfhtml.org/self/2017/apr/14/kontaktformular-und-utf8-strich-unicode/1692157#m1692157" rel="noopener noreferrer">wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.</a></p> </blockquote> <p>Deine dortige "Begründung" würde höchstens zutreffen für den Fall, daß</p> <ol> <li>der Content-Type+Charset Header generell gesetzt</li> <li>es während dieser Zeit Dokumente gibt auf denen die im Header deklarierte Chrsetangabe nicht zutrifft.</li> </ol> <p>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.</p> <p>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.</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738560#m1738560 beatovich https://beat-stoecklin.ch/pub/musik-gitarrenunterricht-laufental.html 2018-12-14T19:38:38Z 2018-12-14T19:38:38Z The character encoding is not specified in the HTTP header <p>hallo</p> <blockquote> <p>Es gibt aber auch Fälle, <a href="https://forum.selfhtml.org/self/2017/apr/14/kontaktformular-und-utf8-strich-unicode/1692157#m1692157" rel="noopener noreferrer">wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.</a></p> </blockquote> <p>Warum sollte ich bei HTML-Dokumenten überhaupt einen http-header ausgeben?</p> <div class="signature">-- <br> <a href="https://beat-stoecklin.ch/pub/index.html" rel="nofollow noopener noreferrer">https://beat-stoecklin.ch/pub/index.html</a> </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738556#m1738556 pl 2018-12-14T18:46:04Z 2018-12-14T18:46:04Z Deine Herangehensweise <p><a href="/users/20" class="mention registered-user" rel="noopener noreferrer">@Gunnar Bittersmann</a></p> <p>es gibt auch hier im Forum Fachkräfte die denken daß sie umso kompetenter erscheinen je überzeugender sie auftreten.</p> <p>Diese Unsitte ist leider auch allgemein stark verbreitet.</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738558#m1738558 Gunnar Bittersmann selfhtml@bittersmann.de https://bittersmann.de 2018-12-14T19:26:46Z 2018-12-14T19:26:46Z Content-Type: text/* <p>@@pl</p> <blockquote> <blockquote> <p>Es gibt aber auch Fälle, <a href="https://forum.selfhtml.org/self/2017/apr/14/kontaktformular-und-utf8-strich-unicode/1692157#m1692157" rel="noopener noreferrer">wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.</a></p> </blockquote> <p>Deine dortige "Begründung" würde höchstens zutreffen für den Fall, daß</p> <ol> <li>der Content-Type+Charset Header generell gesetzt</li> <li>es während dieser Zeit Dokumente gibt auf denen die im Header deklarierte Chrsetangabe nicht zutrifft.</li> </ol> </blockquote> <p>Genau das war dort ja der Fall. Was also ist dein Punkt?</p> <p>BTW, wenn du Text mit Leerzeichen einrückst, wird das als Code markiert (nachzulesen in der <a href="https://wiki.selfhtml.org/wiki/SELFHTML:Forum/Formatierung_der_Beitr%C3%A4ge" rel="nofollow noopener noreferrer">Hilfe</a>). Ich hab die Formatierung deines Postings mal berichtigt.</p> <blockquote> <p>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.</p> </blockquote> <p>Deine logischen Schlüsse sind immer wieder beeindruckend. Nicht.</p> <blockquote> <p>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.</p> </blockquote> <p>Auch darüber solltest du nochmal nachdenken.</p> <p>LLAP </p> <div class="signature">-- <br> <em>„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“</em> —Kurt Weidemann </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738569#m1738569 pl 2018-12-15T08:45:52Z 2018-12-15T08:45:52Z Content-Type: text/* <p><a href="/users/20" class="mention registered-user" rel="noopener noreferrer">@Gunnar Bittersmann</a></p> <p>Eine Charsetangabe zum Content-Type <code>text</code> mach immer Sinn. Daran hält sich sogar XMLHttpRequest:</p> <pre><code class="block language-js"><span class="token keyword">var</span> xhr <span class="token operator">=</span> <span class="token keyword">new</span> <span class="token class-name">XMLHttpRequest</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">;</span> xhr<span class="token punctuation">.</span><span class="token function">open</span><span class="token punctuation">(</span><span class="token string">'POST'</span><span class="token punctuation">,</span><span class="token string">'%url%'</span><span class="token punctuation">)</span><span class="token punctuation">;</span> xhr<span class="token punctuation">.</span><span class="token function">send</span><span class="token punctuation">(</span><span class="token constant">JSON</span><span class="token punctuation">.</span><span class="token function">stringify</span><span class="token punctuation">(</span><span class="token punctuation">[</span><span class="token number">1</span><span class="token punctuation">,</span><span class="token number">2</span><span class="token punctuation">,</span><span class="token number">3</span><span class="token punctuation">]</span><span class="token punctuation">)</span><span class="token punctuation">)</span><span class="token punctuation">;</span> </code></pre> <p>und generiert spontan einen Requestheader <code>Content-Type: text/plain;charset=UTF-8</code></p> <p>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!</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738565#m1738565 pl 2018-12-15T07:55:51Z 2018-12-15T07:55:51Z The character encoding is not specified in the HTTP header <p>hallo</p> <blockquote> <p>Warum sollte ich bei HTML-Dokumenten überhaupt einen http-header ausgeben?</p> </blockquote> <p>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.</p> <p>Und wenn Du Deine HTML-Dokumente per DHL versendest ist das sicher ähnlich. Welche Instanz also vermeldet denn sowas: <code>The character encoding is not specified in the HTTP header</code></p> <p>???</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738578#m1738578 pl 2018-12-15T10:27:26Z 2018-12-15T10:27:26Z The character encoding is not specified in the HTTP header <p>hallo</p> <blockquote> <blockquote> <p>Es gibt aber auch Fälle, <a href="https://forum.selfhtml.org/self/2017/apr/14/kontaktformular-und-utf8-strich-unicode/1692157#m1692157" rel="noopener noreferrer">wo man besser keine Zeichencodierungsangabe im HTTP-Header hat.</a></p> </blockquote> <p>Warum sollte ich bei HTML-Dokumenten überhaupt einen http-header ausgeben?</p> </blockquote> <p>Die Frage ist berechtigt. Denn es gibt ja auch HTTP-Trailer!</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738570#m1738570 Gunnar Bittersmann selfhtml@bittersmann.de https://bittersmann.de 2018-12-15T09:04:21Z 2018-12-15T09:04:21Z Content-Type: text/* <p>@@pl</p> <blockquote> <p>Eine Charsetangabe zum Content-Type <code>text</code> mach immer Sinn.</p> </blockquote> <p>Das mag ja sein. Das ändert aber nichts daran, dass deine Aussage <em>„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“</em> falsch ist.</p> <p>LLAP </p> <div class="signature">-- <br> <em>„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“</em> —Kurt Weidemann </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738574#m1738574 pl 2018-12-15T10:04:23Z 2018-12-15T10:17:49Z Content-Type: text/* <p><a href="/users/20" class="mention registered-user" rel="noopener noreferrer">@Gunnar Bittersmann</a></p> <p>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!</p> <p>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.</p> <p>Bei einem Content-Type text/plain (ohne Charsetangabe) hingegen wird ein Browser möglicherweise versuchen, anhand einer etwa vorhandenen BOM die Kodierung zu ermitteln.</p> <p>MfG</p> <p>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!</p> <p>D.h., daß man nicht davon ausgehen kann, daß ein HTTP Client bei text/plain die Kodierung am Inhalt erkennt!</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738579#m1738579 Gunnar Bittersmann selfhtml@bittersmann.de https://bittersmann.de 2018-12-15T10:31:05Z 2018-12-15T10:31:05Z Content-Type: text/* <p>@@pl</p> <blockquote> <p>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!</p> </blockquote> <p>??</p> <p>Wenn der Empfänger im Bytestream EF BB BF liest, dann <em>ist</em> es ein BOM.<br> Wenn der Empfänger im Bytestream FE FF liest, dann <em>ist</em> es ein BOM.<br> Wenn der Empfänger im Bytestream FF FE liest, dann <em>ist</em> es ein BOM.</p> <blockquote> <p>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.</p> </blockquote> <p>Auf zwei Arten:</p> <ol> <li>BOM</li> <li><code>charset="…"</code></li> </ol> <blockquote> <p>Bei einem Content-Type text/plain (ohne Charsetangabe) hingegen wird ein Browser möglicherweise versuchen, anhand einer etwa vorhandenen BOM die Kodierung zu ermitteln.</p> </blockquote> <p>Was eben auch eine Deklaration der Zeichencodierung im Dokument selbst ist.</p> <p>LLAP </p> <div class="signature">-- <br> <em>„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“</em> —Kurt Weidemann </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738581#m1738581 beatovich https://beat-stoecklin.ch/pub/musik-gitarrenunterricht-laufental.html 2018-12-15T10:35:36Z 2018-12-15T10:35:36Z Content-Type: text/* <p>hallo</p> <blockquote> <p><a href="/users/20" class="mention registered-user" rel="noopener noreferrer">@Gunnar Bittersmann</a></p> <p>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!</p> </blockquote> <p>Eine Verienbarung ist eine Einigung zwischen mehreren Partnern wobei alle frei sein müssen, zwischen mehreren Optionen sich zu entscheiden.</p> <p>Ich wüsste nicht, wie ein CGI Prozess frei ist, eine shebang Zeile mit oder ohne BOM zu lesen.</p> <blockquote> <p>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.</p> </blockquote> <p>...so wie auch andere Fileformate Informationen enthalten, die für den Parser relevant sind.</p> <p>Ich hatte im übrigen da mal eine Beobachtung:</p> <p><a href="https://forum.selfhtml.org/self/2018/aug/20/msie-11-ein-paar-beobachtungen/1729448#m1729448" rel="noopener noreferrer">https://forum.selfhtml.org/self/2018/aug/20/msie-11-ein-paar-beobachtungen/1729448#m1729448</a></p> <p>Betrifft MSIE 10 xhr-Zugriff auf Datei ohne BOM.</p> <div class="signature">-- <br> <a href="https://beat-stoecklin.ch/pub/index.html" rel="nofollow noopener noreferrer">https://beat-stoecklin.ch/pub/index.html</a> </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738585#m1738585 pl 2018-12-15T10:59:53Z 2018-12-15T10:59:53Z Content-Type: text/* <p><a href="/users/20" class="mention registered-user" rel="noopener noreferrer">@Gunnar Bittersmann</a></p> <p>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.</p> <p>Ergo genügt die Angabe text/hml.</p> <pre><code> > 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. </code></pre> <p>Nein ist es nicht. Aber wahrscheinlich suchst Du nur Streit. Lass es einfach!</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738587#m1738587 beatovich https://beat-stoecklin.ch/pub/musik-gitarrenunterricht-laufental.html 2018-12-15T11:16:03Z 2018-12-15T11:24:02Z Content-Type: text/* <p>hallo</p> <blockquote> <p>@@pl</p> <blockquote> <p>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!</p> </blockquote> <p>??</p> <p>Wenn der Empfänger im Bytestream EF BB BF liest, dann <em>ist</em> es ein BOM.<br> Wenn der Empfänger im Bytestream FE FF liest, dann <em>ist</em> es ein BOM.<br> Wenn der Empfänger im Bytestream FF FE liest, dann <em>ist</em> es ein BOM.</p> </blockquote> <p>Am anfang des Bytestroms. Und das ist nur der Fall, weil der Empfänger zu einer Auflösung nach U+FFFE gelangt.</p> <p>Es gibt im übrigen noch sehr viel mehr Muster.</p> <p><a href="https://de.wikipedia.org/wiki/Byte_Order_Mark" rel="nofollow noopener noreferrer">https://de.wikipedia.org/wiki/Byte_Order_Mark</a></p> <div class="signature">-- <br> <a href="https://beat-stoecklin.ch/pub/index.html" rel="nofollow noopener noreferrer">https://beat-stoecklin.ch/pub/index.html</a> </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738586#m1738586 pl 2018-12-15T11:15:26Z 2018-12-15T11:16:00Z Content-Type: text/* <p>Es gibt für HTTP einen Default Enctype: <code>application/x-www-form-urlencoded</code></p> <p>und der ist von der Zeichenkodierung unabhängig weil die darauf aufsetzende Prozentkodierung bytesemantisch arbeitet.</p> <blockquote> <p>...so wie auch andere Fileformate Informationen enthalten, die für den Parser relevant sind.</p> </blockquote> <p>Nein. Relevant für einen Parser ist einzig der Content-Type! Und da ein Parser bytesemantisch arbeitet ist die Zeichenkodierung völlig nebensächlich.</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738658#m1738658 pl 2018-12-16T09:00:53Z 2018-12-16T09:00:53Z Content-Type: text/* <p>hallo</p> <blockquote> <p>Ich wüsste nicht, wie ein CGI Prozess frei ist, eine shebang Zeile mit oder ohne BOM zu lesen.</p> </blockquote> <p>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.</p> <p>BOM, Browser und XHR.. da kommt Freude auf am Programmiertisch. Mach Dir einen schönen Tag damit </p> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738592#m1738592 Gunnar Bittersmann selfhtml@bittersmann.de https://bittersmann.de 2018-12-15T11:45:25Z 2018-12-15T11:45:25Z Content-Type: text/* <p>@@pl</p> <blockquote> <p>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.</p> </blockquote> <p>Du irrst.</p> <p>Für die Angabe der Zeichencodierung ist kein HTML-Element zuständig, sondern allein die Zeichenkette <code>charset="…"</code>. (Wobei <code>…</code> für eine gültigen Zeichencodierungsbezeichner steht und statt <code>"</code> auch <code>'</code> oder gar nichts stehen kann.)</p> <p>Die HTML-Version hat damit gar nichts zu tun. Eben deshalb konnte man ja <code class="language-html"><span class="token tag"><span class="token tag"><span class="token punctuation"><</span>meta</span> <span class="token attr-name">charset</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>…<span class="token punctuation">"</span></span><span class="token punctuation">></span></span></code> einführen, weil auch Prä-HTML5-Parser das auswerten konnten.</p> <p>Das <code>meta</code>-Element hat den Zweck, die Angabe regelkonform in HTML-Syntax unterzubringen.</p> <p>Moment mal, dann sollte eigentlich auch <code class="language-html"><span class="token tag"><span class="token tag"><span class="token punctuation"><</span>html</span> <span class="token attr-name">charset</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>…<span class="token punctuation">"</span></span><span class="token punctuation">></span></span></code> als Zeichencodierungsangabe funktionieren.</p> <p>Oder sogar auch <code class="language-html"><span class="token comment"><!-- charset="…" --></span></code>? Da müsste ich aber erstmal nachlesen, ob der Parser auch in Kommentaren sucht.</p> <p></p> <blockquote> <p>Aber wahrscheinlich suchst Du nur Streit. Lass es einfach!</p> </blockquote> <p>Du gibst <a href="https://forum.selfhtml.org/self/2018/dec/12/cast-string-oder-new-string/1738502#m1738502" rel="noopener noreferrer">mir</a> mal wieder recht. Schade eigentlich.</p> <p>LLAP </p> <div class="signature">-- <br> <em>„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“</em> —Kurt Weidemann </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738589#m1738589 Gunnar Bittersmann selfhtml@bittersmann.de https://bittersmann.de 2018-12-15T11:28:42Z 2018-12-15T11:28:42Z Content-Type: text/* <p>@@beatovich</p> <blockquote> <blockquote> <p>Wenn der Empfänger im Bytestream EF BB BF liest, dann <em>ist</em> es ein BOM.<br> Wenn der Empfänger im Bytestream FE FF liest, dann <em>ist</em> es ein BOM.<br> Wenn der Empfänger im Bytestream FF FE liest, dann <em>ist</em> es ein BOM.</p> </blockquote> <p>Am anfang des Bytestroms.</p> </blockquote> <p>Ja. Ich hatte schon im Kopf, das nach dem Frühstück noch zu berichtigen. Du warst schneller.</p> <blockquote> <p>Und das ist nur der Fall, weil der Empfänger zu einer Auflösung nach U+FFFE gelangt.</p> </blockquote> <p>??</p> <blockquote> <p>Es gibt im übrigen noch sehr viel mehr Muster.</p> </blockquote> <p>Ja. Ich wollte mich hier auf die relevante und die nicht gänzlich irrelevante Unicode-Codierung beschränken.</p> <p>LLAP </p> <div class="signature">-- <br> <em>„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“</em> —Kurt Weidemann </div> https://forum.selfhtml.org/self/2018/dec/13/the-character-encoding-is-not-specified-in-the-http-header/1738595#m1738595 pl 2018-12-15T12:21:22Z 2018-12-15T12:21:22Z Content-Type: text/* <p>hallo</p> <blockquote> <blockquote> <p>Wenn der Empfänger im Bytestream EF BB BF liest, dann <em>ist</em> es ein BOM.</p> </blockquote> </blockquote> <p>Es sind 3 Zeichen: </p> <p>Ob diese 3 Zeichen ein BOM sein sollen ist eine Frage der Vereinbarung!</p> <blockquote> <p>Am anfang des Bytestroms. Und das ist nur der Fall, weil der Empfänger zu einer Auflösung nach U+FFFE gelangt.</p> </blockquote> <p><code>Unicode non-character 0xfffe is illegal for interchange</code> sagt eine ältere Perlversion.</p> <p>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 ￾</p> <p>MfG</p>