Umlaute in einer POST-Variable mit DB vergleichen?

[Edgar Ehritt]

Hallo Chrisb,

Allein aus den Erfahrungen der Vergangenheit, was die richtige Interpretation von Zeichencodierungen anbelangt, ist der Normalzustand der, dass man auf mögliche Browserfehler hin mit benannte Zeichen präventivert;

Dann gib' doch mal Butter bei die Fische, und beschreibe, welche Probleme es mit gängigen Zeichenkodierungen heutzutage gibt, die der Einsatz von Entity-Notation lösen würde.

Der grundlegende Gedanke wird doch aus dem Problemvortrag Markus' ersichtlich, welche Probleme es mit gängigen Zeichenkodierungen heutzutage gibt. Er sieht im Browser statt eines ä ein �. Welcher Browser das sein kann, ist unerheblich. Zu diesen unerwünschten Anzeigen kommt es, wenn entweder die angegebene Zeichenkodierung von UTF-8 falsch ist, oder keine angegeben wurde und der Browser diese auf UTF-8 bestimmt (unter der Maßgabe, dass das Dokument nicht UTF-8-codiert wurde).

Ein Einwand, der sich explizit an "Browserfehler" stören würde, ist ja richtig. Heute gibt es nicht mehr das Problem, offline-verfügbarer Dokumente. Heutige Browser sind sehr präzise bei der automatischen Bestimmung von Zeichensätzen geworden. Insofern will ich relativieren. Es sind keine Browserfehler (obwohl ich das mangels Standard der Priorität der Angaben, wie unten etwas näher dargetan, durchaus für umstritten ansehe). Ich spreche besser von Anzeigefehlern im Hinblick darauf, was als Anzeige vom Otto-Normalverbraucher ohne Konfigurationkenntnisse erwartet wird.

Was die Angabe der Zeichenkodierung betrifft, gab es meiner Erinnerung nach in den letzten Jahren auch ein uneinheitliches Verhalten einzelner Browser, was die Rangfolge betrifft. Konkurrierende Angaben im HTT-Protokoll wider Metaangaben wurden also nicht immer gleich aufgelöst. Heute stellt sich das meines Kenntnisstands nach einheitlich dar. Die Rangfolge ist also erst, Angaben des Protokolls zu befolgen. Dann kommen Angaben des Dokuments selbst in Form der Metaangaben. Zum Schluss wird erst versucht, die Zeichenkodierung zu bestimmen. (Da bestand mangels informationstragendem Protokoll bei so genannten offline-Dikumenten ein Problem.)
 Dazu gibt es meines Wissens aber keinen verlässlichen Standard, auf dessen Basis man sich berufen könnte. Kritisch sehe ich hier auch, a priori wird dem Protokoll eine höhere Stellung eingeräumt. Dabei ist zum einen Fakt, dass die Mehrheit aller Web-Autoren insbesondere nach eigenem Kenntnisstand sich um diese Angabe nicht kümmern oder kümmern können - nicht zuletzt weil sie keinen Einblick in das Protokoll haben. Hier ist bereits oberes Ende, valides HTML zu schreiben/schreiben zu lassen. Zum anderen hat ein Web-Autor sich eigentlich auch nur um seine Dokumente zu kümmern, denn alles andere wäre Serverkonfiguration. Jedoch verlangt die heutige Rangfolge Kenntnis der Serverkonfiguration.
 Diese den Autoren auch noch überzuhelfen, halte ich für verfehlt. (Das ich mit dieser Meinung hier im Forum wohl eher alleine stehe, ist mir seit der Diskussion mit Martins Meinung, alle haben hier programmieren zu lernen und werden auch so behandelt, klar.) Ein wirklich guter Ansatz diese Diskrepanz zwischen administrativer Arbeit und eigentlichem Erstellen von Inhalten wäre ein Servermodul, was die Angaben der des <meta>-Elements analysiert und als HTTP-Header ausgibt. Dies trüge der tatsächlichen Bedeutung dieses Elements Rechnung. Damit erschiene mir die Priorität der Angaben dann auch als gerechtfertigt.
 Damit will ich sagen, dass ich den status quo der Prioritäten mit Blick auf diese Diskrepanz für unvernünftig halte. Vielleicht sieht das bei den Browserentwicklern irgendwann auch wieder eine Mehrheit. Mangels Standards kann es dann wieder zu uneinheitlichen Anzeigen führen...

Bezogen auf Markus' Problem ist der »Sonderfall« des Gebrauchs Benannter Zeichen eine Lösung. Aber sehen wir doch mal über den Einzelfall hinweg. Selbst große Projekte haben mit der Zeichenkodierung immer wieder Probleme. Die online abrufbare Dokumentation PHPs war jahrelang von Zeichencodierungsfehlern übersät. Irgendwann hatte man sich an die vielen ä, ö und ü gewöhnt. Allgemein laufen Großprojekte zusehend Gefahr, ein patchwork aus verschiedenen Komponenten zu werden. Das Betrifft meiner Kenntnis nach nicht die Dokumentation PHPs; aber beispielsweise SELFHTML (vgl. file uploads).

Der Trennt scheint mir immer mehr dahin zu gehen, Applikationen (CMS) bereitzustellen, dabei aber den Autor vor der Kenntnis der eigentlich eingesetzten technischen Grundlage, also HTTP, CGI, HTML, CSS, Javascript, Flash, Java, etc., zu entfernen. Für ein Problem beim Publizieren von Inhalten gibt es allermeist mehrere (relativ) fertige Anwendungen. Das führt ja letztendlich zu den erwähnten patchworks. Diese bieten nicht immer adäquate Möglichkeiten der Konfiguration. Die Folge ist, es kommt wieder zu Anzeigefehlern. Doch die Entfernung des Autors bleibt und es kommt ein typisches "geht nicht".
 Aus Sicht des Programmierers, der solche Applikationen entwickelt, macht es daher erheblich mehr Sinn, Benannte Zeichen zu verwenden. Er kann zwar für abweichende Konfigurationen, unter die seine Applikation laufen wird, nichts. Sie fallen aber auf sein eigenes Projekt zurück. Dabei gibt es bei beispielsweise einer PHP-Applikation gleich drei mögliche Fehlerherde. Das sind der Webserver, PHP und das Dokument selbst (templates). Sowohl für die Konfiguration des Webserver, als auch PHP sind Einschränkungen möglich, konfigurative Angaben des Zeichensatzes zu unterbinden. PHP hat zwar mit header() die Möglichkeit, den Zeichensatz festzusetzen. Das jedoch setzt wiederum voraus, dass der Web-Autor doch wieder Konfigurieren müsste und sich also mit der Materie der Zeichenkodierungen herum zu plagen hat. Zum anderen ist im handler-Gefüge der einzelnen Webservers die Zeichensatzangabe nicht unbedingt unumstößlich. Ausweg aus diesen Problemen sind hier Benannte Zeichen.

Von der oben angerissenen Diskrepanz wischen Web-Autoren, deren unterstelltes Ziel es sei, Inhalte zu publizieren und sich nicht mit administrativen Aufgaben herum zu plagen, insbesondere aber vom Trennt des Web 2.0 (jetzt musste ich dieses Unwort doch tippen) her über die daraus notwen kann es heute eigentlich nur eine Bewertung geben: Benannte Zeichen (alias Entity-Notation) sind die Universallösung von Anzeigeproblemen. Sie sind keinesfalls »Sonderfall«.

Ist das (Dir) ohnehin Offensichtliche nunmehr klar dargelegt?

Gruß aus Berlin!
eddi