Kontaktformular & UTF8/Unicode

[Gunnar Bittersmann]

@@pl

Das ist ja nun kompletter Quatsch

Bringen wir das mal in den historischen Kontext: Wann immer es hier um Zeichencodierung ging, hat dedlfix fachlich gehaltvolle Beiträge beigesteuert. Deine Beiträge hingegen habe ich als bestenfalls neutral, aber eher der anderen Seite des Spektrums zugehörig in Erinnerung.

Nun könnte es sein, dass dedlfix inzwischen senil geworden ist oder dass du was dazugelernt hättest. Aber ich denke, weder das Eine noch das Andere ist hier der Fall.

Warum sollte die Angabe der Zeichenkodierung im Dokument von der im Content-Type-Header gesendeten abweichen?

Sollte sie (bestenfalls) nicht. Das stiftet nur Verwirrung, welche Angabe denn nun a) die richtige und b) die gültige ist.

Wenn es nur eine Angabe (entweder im Dokument oder im HTTP-Header) gibt, kann da nichts voneinander abweichen.

Stell dir mal eine umfangreiche Website vor, voller Altlasten in ISO 8859-1 codiert. Das möchte man ändern und UTF-8 verwenden – bei neuen Seiten oder denen, die man gerade überarbeitet. (Für die anderen gibt es keinen Grund, die Zeichencodierung zu ändern, der den Aufwand rechtfertigen würde.)

Wenn der Server keine Zeichencodierung im HTTP-Header angibt, kein Problem: im Dokument UTF-8 angeben, mit UTF-8 speichern – fertig.

Wenn der Server aber ISO 8859-1 im HTTP-Header angibt, dann hat man ein Problem.

Und selbstverständlich kann ein als Default gesetzter Content-Type jederzeit überschrieben werden

Das wäre zwar möglich, aber wartungsintensiv: Man müsste jedes neue/geänderte Dokument seinen Content-Type mit PHP selbst setzen lassen oder in .htaccess eine Liste der bereits UTF-8-codierten Ressourcen pflegen.

Die andere Möglichkeit, UTF-8 mit BOM zu verwenden, was höhere Priorität hat als die Angabe im HTTP-Header, scheitert daran, dass sie das in IrgendEinem Browser nicht hat; und an der Problematik der Unsichtbarkeit.

TL;DR: Es gibt Fälle, in denen es sinnvoll und hilfreich ist, dass der Server keine Zeichencodierung angibt.

LLAP 🖖