Umlaute in einer POST-Variable mit DB vergleichen?

[markus_walther]

Hi!

Ich habe eine Frage zu Umlauten in HTML bzw. PHP. In HTML wird ? z.B. als ß geschrieben. Mein Server nimmt auch nichts anderes an, das heißt tippt man irgendwo "ü" anstatt "ü" ein, kommt ein fragezeichen, anstatt des "ü"'s.

Ich möchte nun eine Usereingabe mit einem Datenbankeintrag vergleichen.
In dem Eintrag sind aber leider Sonderzeichen enthalten.
Wenn ich die POST-Variable mit dem DB-Eintrag vergleiche, bekomme ich keine Bestätigung, dass die beiden Daten gleich sind, wahrscheinlich, weil in der POST-Variable schon dieses Fragezeichen, anstatt dem (z.B.) ü ist. Ich habe versucht per $loesung = str_replace("ü","ue",$_POST['loesung']); das Problem zu beheben, aber leider funktioniert auch dies nicht, da wahrscheinlich auch hier schon das Fragezeichen anstatt des Umlautes eingefügt wurde. Weiß jemand wie ich das ändern kann? ;)

Bin für jede Hilfe dankbar.

LG
Markus

[Der Martin]

Hallo,

In HTML wird ? z.B. als ß geschrieben.

auch wenn das jetzt ein Koordinationsproblem zwischen deinem Finger und der Shift-Taste war und du das Zeichen 'ß' meintest: Nein, als ß sollte man es nur in Ausnahmefällen schreiben. Normalerweise sollte man Zeichen im Klartext notieren.

Mein Server nimmt auch nichts anderes an, das heißt tippt man irgendwo "ü" anstatt "ü" ein, kommt ein fragezeichen, anstatt des "ü"'s.

Dann hast du wahrscheinlich ein Problem mit nicht übereinstimmenden Textcodierungen. Irgendeine Komponente hat unsinnigerweise versucht, das Nicht-ASCII-Zeichen umzucodieren und ist gescheitert, hat also ersatzweise ein Fragezeichen eingetragen.

Ich möchte nun eine Usereingabe mit einem Datenbankeintrag vergleichen. [...]

Bevor du jetzt anfängst, Symptome zu bekämpfen, solltest du lieber nach der Ursache forschen und die beseitigen. Es ist zwecklos, Motten punktuell mit der Fliegenklatsche zu erledigen (von der Sauerei ganz abgesehen), während eine Brutstätte in der Haferflockenpackung ist.

Untersuche also die beteiligten Komponenten: Editor, tatsächliche Codierung des HTML/PHP-Quelltextes, Einstellungen des Webservers und der Datenbank, sowie der Verbindung zwischen PHP und der Datenbank. Nur wenn überall die gleiche Codierung verwendet wird, hast du eine reelle Chance auf ein stressfreies Arbeiten.

So long,
 Martin

[Edgar Ehritt]

Hallo,

In HTML wird ? z.B. als ß geschrieben.
Nein, als ß sollte man es nur in Ausnahmefällen schreiben. Normalerweise sollte man Zeichen im Klartext notieren.

es wäre schön, wenn Du auch schreiben würdest, warum man etwas nach Deinem Gusto machen sollte. In http://de.selfhtml.org/html/allgemein/zeichen.htm#umlaute@title=SELFHTML ist jedenfalls folgendes zu lesen:

Dennoch gibt es einige Sonderfälle, in denen es sinnvoll ist, sich auf
   die Seite ASCII-Zeichen zu beschränken, um mögliche Probleme bei der
   Verarbeitung zu vermeiden. In diesem Fall können Sie deutsche Umlaute
   sowie das scharfe S durch benannte Zeichen umschreiben. Das gilt für
   den gesamten Inhalt einer HTML-Datei.

Mein Server nimmt auch nichts anderes an, das heißt tippt man irgendwo "ü" anstatt "ü" ein, kommt ein fragezeichen, anstatt des "ü"'s.
Dann hast du wahrscheinlich ein Problem mit nicht übereinstimmenden Textcodierungen. Irgendeine Komponente hat unsinnigerweise versucht, das Nicht-ASCII-Zeichen umzucodieren und ist gescheitert, hat also ersatzweise ein Fragezeichen eingetragen.

Es ist unwahrscheinlich, dass der Server tatsächlich einen Inputfilter nutzt. Viel wahrscheinlicher handelt es sich nur um eine fehlende oder fehlerhafte Angabe der Zeichenkodierung.

Ich möchte nun eine Usereingabe mit einem Datenbankeintrag vergleichen. [...]

Bevor du jetzt anfängst, Symptome zu bekämpfen, solltest du lieber nach der Ursache forschen und die beseitigen. Es ist zwecklos, Motten punktuell mit der Fliegenklatsche zu erledigen (von der Sauerei ganz abgesehen), während eine Brutstätte in der Haferflockenpackung ist.

Untersuche also die beteiligten Komponenten: Editor, tatsächliche Codierung des HTML/PHP-Quelltextes, Einstellungen des Webservers und der Datenbank, sowie der Verbindung zwischen PHP und der Datenbank. Nur wenn überall die gleiche Codierung verwendet wird, hast du eine reelle Chance auf ein stressfreies Arbeiten.

Wie schön sind da immer wieder ein paar weiterführende Links, statt einem Fragenden das an den Kopf zu klatschen.
Was soll er denn jetzt machen? Nach Motten und Haferflocken googeln? Über leg doch mal, welchen Hilfegehalt Deine Aussagen haben!

Gruß aus Berlin!
eddi

[Der Martin]

Hi,

In HTML wird ? z.B. als ß geschrieben.
Nein, als ß sollte man es nur in Ausnahmefällen schreiben. Normalerweise sollte man Zeichen im Klartext notieren.

In http://de.selfhtml.org/html/allgemein/zeichen.htm#umlaute@title=SELFHTML ist jedenfalls folgendes zu lesen:
   Dennoch gibt es einige Sonderfälle, in denen es sinnvoll ist, ...

danke für die Bestätigung. Genau das ist es, was "normalerweise" impliziert: Dass es Ausnahmen von der Regel gibt.

Dann hast du wahrscheinlich ein Problem mit nicht übereinstimmenden Textcodierungen. Irgendeine Komponente hat unsinnigerweise versucht, das Nicht-ASCII-Zeichen umzucodieren und ist gescheitert, hat also ersatzweise ein Fragezeichen eingetragen.
Es ist unwahrscheinlich, dass der Server tatsächlich einen Inputfilter nutzt.

Das hat auch niemand behauptet.

Viel wahrscheinlicher handelt es sich nur um eine fehlende oder fehlerhafte Angabe der Zeichenkodierung.

Das dagegen schrieb ich im oben zitierten Absatz.

Untersuche also die beteiligten Komponenten: Editor, tatsächliche Codierung des HTML/PHP-Quelltextes, Einstellungen des Webservers und der Datenbank, sowie der Verbindung zwischen PHP und der Datenbank. Nur wenn überall die gleiche Codierung verwendet wird, hast du eine reelle Chance auf ein stressfreies Arbeiten.
Wie schön sind da immer wieder ein paar weiterführende Links, statt einem Fragenden das an den Kopf zu klatschen.

Wozu Links, wenn ich das, was ich verlinken könnte, stattdessen explizit hinschreibe?

Über leg doch mal, welchen Hilfegehalt Deine Aussagen haben!

Überleg du bitte mal, welchen Hilfegehalt deine Provokationen haben. Aus sicherer Ferne habe ich mitgelesen, wie Gunnar vor ein paar Tagen anscheinend Spaß daran hatte, auf deine Provokationen einzugehen (anfangs jedenfalls, nachher offensichtlich nicht mehr). Ich habe diesen Spaß nicht; du wirst es zwar nicht verstehen, aber ich ziehe es daher vor, auf weitere Pöbeleien von dir nicht mehr zu reagieren.

Ciao,
 Martin

[Edgar Ehritt]

Hallo,

In HTML wird ? z.B. als ß geschrieben.
Nein, als ß sollte man es nur in Ausnahmefällen schreiben. Normalerweise sollte man Zeichen im Klartext notieren.

In http://de.selfhtml.org/html/allgemein/zeichen.htm#umlaute@title=SELFHTML ist jedenfalls folgendes zu lesen:
   Dennoch gibt es einige Sonderfälle, in denen es sinnvoll ist, ...

danke für die Bestätigung. Genau das ist es, was "normalerweise" impliziert: Dass es Ausnahmen von der Regel gibt.

da wird nichts bestätigt. 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; genauso wie man ein Web auch funktionsfähig hält, bei deaktiviertem Javascript. Ich sehe den Sonderfall hier als maximale Fehlereindämmung.

Wozu Links, wenn ich das, was ich verlinken könnte, stattdessen explizit hinschreibe?

Weil es in dem Fall offensichtlich ist, was geholfen hat. Deine nicht näher benannten "Komponenten" waren es nicht.

Aus sicherer Ferne habe ich mitgelesen, wie Gunnar vor ein paar Tagen anscheinend Spaß daran hatte, auf deine Provokationen einzugehen (anfangs jedenfalls, nachher offensichtlich nicht mehr).

Ja, ich war mittenmang, mich mit den teilweise wirklich abstrusen Einwürfen allein auseinander zusetzen.

du wirst es zwar nicht verstehen, aber ich ziehe es daher vor, auf weitere Pöbeleien von dir nicht mehr zu reagieren.

Das ist deutlich zu sehen. Pöbelei? Kritik! In Teilen war sie berechtigt.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

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.

MfG ChrisB

[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

[Edgar Ehritt]

Den letzten Teil schreibe ich wohl lieber nochmals:

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«.

Von der oben angerissenen Diskrepanz wischen deren unterstelltes Ziel eines Web-Autors, Inhalte zu publizieren und sich nicht mit administrativen Aufgaben herum zu plagen, insbesondere aber vom Trennt des Web 2.0 her über die daraus notwendigen Konsequenzen für den Programmierer kann es heute eigentlich nur eine Bewertung geben: Benannte Zeichen sind die Universallösung von Anzeigeproblemen. Sie sind keinesfalls »Sonderfall«.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Bezogen auf Markus' Problem ist der »Sonderfall« des Gebrauchs Benannter Zeichen eine Lösung.

Nein - lediglich ein Workaround, und zwar ein heutzutage mehr als unnötiger.

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 Leute, die nur publizieren wollen, ja auch durchaus OK.

Aus Sicht des Programmierers, der solche Applikationen entwickelt, macht es daher erheblich mehr Sinn, Benannte Zeichen zu verwenden.

Nein, m.E. ganz und gar nicht.

Er kann zwar für abweichende Konfigurationen, unter die seine Applikation laufen wird, nichts. Sie fallen aber auf sein eigenes Projekt zurück.

Nötige Konfiguration wird dokumentiert, und fertig.

Wer mit so ein System nur als reiner Benutzer konfrontiert sein will - der muss gff. die Administration an jemanden auslagern, der mehr davon versteht.

[...] kann es heute eigentlich nur eine Bewertung geben: Benannte Zeichen (alias Entity-Notation) sind die Universallösung von Anzeigeproblemen. Sie sind keinesfalls »Sonderfall«.

Sie sind ein Relikt aus dem vergangenen Jahrtausend.
Sie als Allheilmittel und Universallösung zu preisen, ist grundfalsch.

MfG ChrisB

[Edgar Ehritt]

Re:

Zu Deinem -nein, nein und nochmals nein- kannst Du Dich ja mal zur Abwechslung in Erklärungen ergießen.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Zu Deinem -nein, nein und nochmals nein- kannst Du Dich ja mal zur Abwechslung in Erklärungen ergießen.

Die von dir genannten Problematiken halte ich zum grössten Teil für nicht vorhanden bzw. theoretischer Natur.

Die Vorteile der direkten Verwendung der Zeichen in einer passenden Kodierung wiegen die potentiellen Nachteile bei weitem auf.

MfG ChrisB

[Edgar Ehritt]

Re:

Zu Deinem -nein, nein und nochmals nein- kannst Du Dich ja mal zur Abwechslung in Erklärungen ergießen.
Die von dir genannten Problematiken halte ich zum grössten Teil für nicht vorhanden bzw. theoretischer Natur

Dass die Dokumentation PHPs bis vor einem dreiviertel Jahr Probleme, die mit Benannten Zeichen nicht sichtbar gewesen wären, mit der Zeichenkodierung hatte, ist für Dich größtenteils nicht vorhanden? Dass der bugtracker SELFHTMLs Zeichen umcodiert, deren Anzeige sich manuell im Browser durch Wahl eines anderen Zeichensatzes nicht korrigieren lässt, ist für Dich theoretischer Natur?

Offensichtlich ist es eben nicht so einfach.

Die Vorteile der direkten Verwendung der Zeichen in einer passenden Kodierung wiegen die potentiellen Nachteile bei weitem auf.

Ein Anzeigefehler ist ein Nachteil. Potentielle Vorteile hast Du immer noch nicht näher erläutert. Insbesondere halte ich Deinen im letzten post vorgetragenen Lösungsvorschlag, Konfigurationen einfach an Leute abzugeben, die es können, an der Realität von shared hosting völlig vorbeigedacht - somit ist dieser theoretischer Natur.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Dass die Dokumentation PHPs bis vor einem dreiviertel Jahr Probleme, die mit Benannten Zeichen nicht sichtbar gewesen wären, mit der Zeichenkodierung hatte, ist für Dich größtenteils nicht vorhanden?

Dass die Jungs da was falsch gemacht haben, ist deren Problem.

Dass der bugtracker SELFHTMLs Zeichen umcodiert, deren Anzeige sich manuell im Browser durch Wahl eines anderen Zeichensatzes nicht korrigieren lässt, ist für Dich theoretischer Natur?

Ich weiss nicht, wo von du hier sprichst.

Ein Anzeigefehler ist ein Nachteil.

Deshalb behebt man ihn, wenn er auftreten sollte.

Potentielle Vorteile hast Du immer noch nicht näher erläutert.

Bspw. das nicht unnötig aufgeblähte Datenvolument.

Insbesondere halte ich Deinen im letzten post vorgetragenen Lösungsvorschlag, Konfigurationen einfach an Leute abzugeben, die es können, an der Realität von shared hosting völlig vorbeigedacht - somit ist dieser theoretischer Natur.

Wenn du immer Gründe suchen willst, warum Konfigurationsmöglichkeiten nicht genutzt werden könnten oder sollten - dann könnte man sie ganz abschaffen.

MfG ChrisB

[Edgar Ehritt]

Re:

Mit anderen Worten: Es kommt immer noch nichts konkretes von Dir. Kein Begründung, warum Benannte Zeichen, die ja Deiner Meinung nach Relikte des letzten Jahrtausends seien, auch wieder in die neue HTML-5-Spezifikation einfließen werden.

Dass die Dokumentation PHPs bis vor einem dreiviertel Jahr Probleme, die mit Benannten Zeichen nicht sichtbar gewesen wären, mit der Zeichenkodierung hatte, ist für Dich größtenteils nicht vorhanden?
Dass die Jungs da was falsch gemacht haben, ist deren Problem.

Dass sie Relikte des letzten Jahrtausends nicht nutzten, ist auch deren Problem.

Dass der bugtracker SELFHTMLs Zeichen umcodiert, deren Anzeige sich manuell im Browser durch Wahl eines anderen Zeichensatzes nicht korrigieren lässt, ist für Dich theoretischer Natur?
Ich weiss nicht, wo von du hier sprichst.

Wenn selbst der Verweis nichts half, was würde dann noch helfen?

Ein Anzeigefehler ist ein Nachteil.
Deshalb behebt man ihn, wenn er auftreten sollte.

Ja. Ich habe dazu einen Vorschlag gemacht, den jeder bei jedem X-beliebigen Anbieter, auf jeder Webserversoftware und ganz ohne Kenntnis über die jeweilige Serverkonfiguration oder den Gebrauch vom Header Content-type anwenden kann. Und wie sieht das bei Deiner zukunftsweisend fortschrittlichen Konfigurationsverpflichtung aus?

Potentielle Vorteile hast Du immer noch nicht näher erläutert.
Bspw. das nicht unnötig aufgeblähte Datenvolument.

Achso; also ist nach Deiner Logik UTF-8 und UTF-16 schlecht™, weil es mehr bytes nutzt? Aber wenn dort Datenvolumen nur beispielhaft genannt ist, was gibt es denn sonnst noch für Vorteile?

Insbesondere halte ich Deinen im letzten post vorgetragenen Lösungsvorschlag, Konfigurationen einfach an Leute abzugeben, die es können, an der Realität von shared hosting völlig vorbeigedacht - somit ist dieser theoretischer Natur.
Wenn du immer Gründe suchen willst, warum Konfigurationsmöglichkeiten nicht genutzt werden könnten oder sollten - dann könnte man sie ganz abschaffen.

Ich habe aber wenigstens nachvollziehbare Gründe, auch wenn sie Dir spitzfindig erscheinen mögen. Es ist die Frage, für wen man programmiert. Geschulte Administratoren gibt es wenige. Teils völlig überforderte, hilflose Web-Autoren gibt es da mehr, wie die Erfahrung des Forumalltags lehrt.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Kein Begründung, warum Benannte Zeichen, die ja Deiner Meinung nach Relikte des letzten Jahrtausends seien, auch wieder in die neue HTML-5-Spezifikation einfließen werden.

Erstens sehe ich nicht, warum sie nicht einfliessen sollten (wie gesagt: Sonderfälle), und zweitens muss ich nicht „begründen“, was die Ersteller von HTML5 in ihre Spezifikation aufnehmen.

Dass der bugtracker SELFHTMLs Zeichen umcodiert, deren Anzeige sich manuell im Browser durch Wahl eines anderen Zeichensatzes nicht korrigieren lässt, ist für Dich theoretischer Natur?
Ich weiss nicht, wo von du hier sprichst.

Wenn selbst der Verweis nichts half, was würde dann noch helfen?

Sorry, du darfst nicht automatisch davon ausgehen, dass ich mir sämtliche deiner Postings in einem Thread durchlese ...

Jetzt, wo ich es mir angesehen habe, ist das Problem offenbar schlicht und einfach, dass dort eine Datei in einer Zeichenkodierung hochgeladen wurde, die von der vom Server verwendeten abweicht.

Da an der Stelle die Daten aber als reiner Text behandelt werden, würden Entities hier auch nicht weiterhelfen.
Es handelt sich hier nicht um ein Problem der Darstellung der Daten (in der ausgebenden HTML-Seite), sondern um eines bei der Interpretation der empfangenen Daten.

Bspw. das nicht unnötig aufgeblähte Datenvolument.

Achso; also ist nach Deiner Logik UTF-8 und UTF-16 schlecht™, weil es mehr bytes nutzt?

Nein.

Ich habe aber wenigstens nachvollziehbare Gründe, auch wenn sie Dir spitzfindig erscheinen mögen. Es ist die Frage, für wen man programmiert. Geschulte Administratoren gibt es wenige. Teils völlig überforderte, hilflose Web-Autoren gibt es da mehr, wie die Erfahrung des Forumalltags lehrt.

Ja, aber das ändert für mich wenig an der grundsätzlichen Betrachtungsweise.

Alles, was es an bestehenden Standards, Spezifikationen etc. gibt wieder einzustampfen (oder zumindest grossflächig zu ignorieren), nur weil es für einige Leute, die gerade anfangen, sich mit der Materie zu beschäftigen, zu komplex sein könnte, kann m.E. keinesfalls der richtige Weg sein.

MfG ChrisB

[Edgar Ehritt]

Re:

Kein Begründung, warum Benannte Zeichen, die ja Deiner Meinung nach Relikte des letzten Jahrtausends seien, auch wieder in die neue HTML-5-Spezifikation einfließen werden.
Erstens sehe ich nicht, warum sie nicht einfliessen sollten (wie gesagt: Sonderfälle), und zweitens muss ich nicht „begründen“, was die Ersteller von HTML5 in ihre Spezifikation aufnehmen.

Keiner hat von dir verlangt zu begründen warum Benannte Zeichen uns erhalten bleiben. Ich hatte dich aber aufgefordert zu begründen, warum sie Relikte des letzten Jahrtausends seien. Zum dritten mal kommt nichts von dir.

Dass der bugtracker SELFHTMLs Zeichen umcodiert, deren Anzeige sich manuell im Browser durch Wahl eines anderen Zeichensatzes nicht korrigieren lässt, ist für Dich theoretischer Natur?
Ich weiss nicht, wo von du hier sprichst.
Wenn selbst der Verweis nichts half, was würde dann noch helfen?
Sorry, du darfst nicht automatisch davon ausgehen, dass ich mir sämtliche deiner Postings in einem Thread durchlese ...

Ich darf automatisch davon ausgehen, dass du dir sämtliche posts von mir, die ich speziell auf deine Anfragen schrieb, durchliest.

Jetzt, wo ich es mir angesehen habe, ist das Problem offenbar schlicht und einfach, dass dort eine Datei in einer Zeichenkodierung hochgeladen wurde, die von der vom Server verwendeten abweicht.

Das ist, wie ich andeutete keinesfalls das Problem. Andernfalls müsste sich das Problem durch manuelles einstellen des Zeichensatzes im Browser beheben lassen. Da es das nicht tut, ich aber weiß welchen Zeichensatz meine Scripte haben, hast du dich immer noch nicht mit einem Argument auseinander gesetzt - vermutlich weil du es immer noch nicht verstanden hast.

Da an der Stelle die Daten aber als reiner Text behandelt werden, würden Entities hier auch nicht weiterhelfen.

Ich lese im Quelltext: <td><span class="cp">&lt;?php</span></td>. Hoppala, ist wohl doch kein reiner Text. Weiterhin kratzt du an der Oberfläche und fällst erneut auf den Mund.

Es handelt sich hier nicht um ein Problem der Darstellung der Daten (in der ausgebenden HTML-Seite), sondern um eines bei der Interpretation der empfangenen Daten.

Es handelt sich also sehr wohl um ein Problem der Darstellung.

Potentielle Vorteile hast Du immer noch nicht näher erläutert.
Bspw. das nicht unnötig aufgeblähte Datenvolument.
Achso; also ist nach Deiner Logik UTF-8 und UTF-16 schlecht™, weil es mehr bytes nutzt? Aber wenn dort Datenvolumen nur beispielhaft genannt ist, was gibt es denn sonnst noch für Vorteile?
Nein.

Damit ist dein Argument »aufgeblähter Datenvolumen« hinfällig.

Wie zu lesen ist, hast du also keine weiteren Argumente und das eine, was du hattest, hast du dir gerade selbst aus der Hand gegeben. Das war zwar zu erwarten, aber von dir hätte ich dann doch mehr erwartet - du "Forumsguru"...

Ich habe aber wenigstens nachvollziehbare Gründe, auch wenn sie Dir spitzfindig erscheinen mögen. Es ist die Frage, für wen man programmiert. Geschulte Administratoren gibt es wenige. Teils völlig überforderte, hilflose Web-Autoren gibt es da mehr, wie die Erfahrung des Forumalltags lehrt.

Ja, aber das ändert für mich wenig an der grundsätzlichen Betrachtungsweise.

Soweit ich erkennen kann, besteht deine grundsätzliche Betrachtungsweise darin, begründungslos Kontra zu geben.

Alles, was es an bestehenden Standards, Spezifikationen etc. gibt wieder einzustampfen (oder zumindest grossflächig zu ignorieren), nur weil es für einige Leute, die gerade anfangen, sich mit der Materie zu beschäftigen, zu komplex sein könnte, kann m.E. keinesfalls der richtige Weg sein.

Es war dir genug Gelegenheit gegeben, Standards, Spezifikationen etc. zu benennen, die deine »grundsätzliche Betrachtungsweise« erhellen würden. Es kam aber nichts konkretes. Daher darfst du ab jetzt automatisch davon ausgehen, dass ich mir keinen deiner posts zu diesem Thema noch durchlesen werde.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Keiner hat von dir verlangt zu begründen warum Benannte Zeichen uns erhalten bleiben. Ich hatte dich aber aufgefordert zu begründen, warum sie Relikte des letzten Jahrtausends seien.

Sie generell für den von dir genannten Zweck einzusetzen, ist vorsintflutlich.

Dass es *Sonderfälle* gibt, wo sie ihre Einsatzberechtigung haben, habe ich nicht bestritten.

Jetzt, wo ich es mir angesehen habe, ist das Problem offenbar schlicht und einfach, dass dort eine Datei in einer Zeichenkodierung hochgeladen wurde, die von der vom Server verwendeten abweicht.

Das ist, wie ich andeutete keinesfalls das Problem.

Das ist das Problem; deine Andeutungen zeigen nur, dass du nicht weisst, wo von du redest.

Andernfalls müsste sich das Problem durch manuelles einstellen des Zeichensatzes im Browser beheben lassen. Da es das nicht tut, ich aber weiß welchen Zeichensatz meine Scripte haben, hast du dich immer noch nicht mit einem Argument auseinander gesetzt - vermutlich weil du es immer noch nicht verstanden hast.

Du bist hier derjenige, der immer noch nicht begriffen hat, wo von die Rede ist.

Es wurde eine Datei ins System hochgeladen, die Bytesequenzen enthält, die in der verwendeten Kodierung nicht erlaubt sind - folglich wurden sie durch Fragezeichen ersetzt, *serverseitig*.

Dass sich diese anschliessend, beim nachfolgenden Abruf, bereits nur noch als Fragezeichen vom Server an den Client ausgelieferten Zeichen nicht magisch in irgendetwas anderes verwandeln, selbst wenn du am Client die Zeichenkodierung, in der der das empfangene darstellen soll, änderst, sollte selbst dir einleuchten.

Da an der Stelle die Daten aber als reiner Text behandelt werden, würden Entities hier auch nicht weiterhelfen.

Ich lese im Quelltext: <td><span class="cp">&lt;?php</span></td>. Hoppala, ist wohl doch kein reiner Text. Weiterhin kratzt du an der Oberfläche und fällst erneut auf den Mund.

Weiterhin beweist du, dass du nicht kapierst, wo von ich rede.

Es wurden reine Textdaten - ein PHP-Beispielscript - auf den Server hochgeladen. Das ist reiner Text - in dem kannst du keine Sonderzeichen durch Entities darstellen.

Das, was du jetzt anführst, ist eine komplett andere Baustelle - nämlich die serverseitig vorgenommene kontextgerechte Behandlung beim Transfer der Textdaten in den Kontext HTML, um sie in einem HTML-Dokument darzustellen.

Noch mal, vielleicht begreifst du es dann endlich:
Die Sonderzeichen, die der Server nicht verarbeiten konnte, sind bereits futsch. Sie wurden durch Fragezeichen ersetzt. Wenn du dieses Fragezeichen bei der Ausgabe jetzt gerne irgendwie kodiert/maskiert notieren willst, kannst du das gerne machen - es ändert aber nichts mehr daran, dass es ein Fragezeichen ist, und nicht mehr das originale, nicht verarbeitbare Zeichen.

Wenn du in der Textdatei, die du per HTTP ins System hochgeladen hast, bereits Entity-Schreibweise verwendet hättest - was ja das angebliche Allheilmittel ist, welches du hier predigst - wäre das aber auch unsinnig gewesen. Weil es sich nun mal um *Text* handelte, und in dem stellt &entity; nur die Zeichen &, e, n, t, i, t, y und ; dar. Du hättest damit gar nicht mehr die Daten hochgeladen, die eigentlich beabsichtigt waren, und keine Verbesserung oder Lösung der Problematik erzielt.

Es handelt sich hier nicht um ein Problem der Darstellung der Daten (in der ausgebenden HTML-Seite), sondern um eines bei der Interpretation der empfangenen Daten.

Es handelt sich also sehr wohl um ein Problem der Darstellung.

Dadurch, dass du auf jeden einzelnen Punkt meines Postings derart antwortest, vervielfachst du nur die Stellen in deiner Antwort, in denen du ganz deutlich zeigst, dass du die Problematik nicht verstanden hast.

Damit ist dein Argument »aufgeblähter Datenvolumen« hinfällig.

Erkläre bitte, warum ein Argument deiner Meinung nach dadurch hinfällig wird, dass es evtl. keine weiteren unabhängigen Argumente gibt.

Das war zwar zu erwarten, aber von dir hätte ich dann doch mehr erwartet - du "Forumsguru"...

Freu dich, du musst mit weniger „Druck“ leben - von dir erwarte ich gar nicht (so) viel.

Dass du jetzt endlich begriffen hast, wo bei obigem dein Denkfehler liegt, will ich aber schon hoffen.

Soweit ich erkennen kann, besteht deine grundsätzliche Betrachtungsweise darin, begründungslos Kontra zu geben.

Huha, das kommt vom richtigen.

Es war dir genug Gelegenheit gegeben, Standards, Spezifikationen etc. zu benennen, die deine »grundsätzliche Betrachtungsweise« erhellen würden. Es kam aber nichts konkretes.

Fang doch mal damit an, dass du dir das hier durchliest:
http://www.w3.org/International/questions/qa-what-is-encoding.de.php

Lass mich raten, die beim W3C haben auch keine Ahnung, und sollten besser auch auf den schlauen Edgar hören?

Daher darfst du ab jetzt automatisch davon ausgehen, dass ich mir keinen deiner posts zu diesem Thema noch durchlesen werde.

Doch, mach mal. Du kannst noch was lernen.

MfG ChrisB

[Edgar Ehritt]

Kurz: Du hast immer noch keine Erklärungen, warum Benannte Zeichen Relikte des letzen Jahrtausends bzw. vorsintflutlich seien, nicht begriffen, dass manches gar nicht durch Konfiguration zu lösen ist (von einem Web-Autor als Laie schon gar nicht), nimmst immer noch keine Stellung dazu, dass du vorgegaukelt hattest, mehrere Vorteile neben deinem Datenvolumenproblem zu sehen und siehst immer noch nicht ein, dass du von Spezifikationen, Standard etc. sprachst, die du nicht benennen kannst, weil es sie wohl gar nicht gibt, die Basis deine »grundsätzliche Betrachtungsweise« sein könnten.

Ich hätte doch konsequent bleiben sollten, statt mir den Morgen zu versauen.

Gruß aus Berlin!
eddi

[Edgar Ehritt]

Hallo Markus,

Ich habe eine Frage zu Umlauten in HTML bzw. PHP. In HTML wird ? z.B. als &szlig; geschrieben. Mein Server nimmt auch nichts anderes an, das heißt tippt man irgendwo "ü" anstatt "&uuml;" ein, kommt ein fragezeichen, anstatt des "ü"'s.

aller Voraussicht nach hat Dein Server keinen Inputfilter. Es fehlt Dir vermutlich nur das Verständnis der Zeichenkodierung - im Dokument, - per HTTP und - von zugesandten Daten.

Ich möchte nun eine Usereingabe mit einem Datenbankeintrag vergleichen.
In dem Eintrag sind aber leider Sonderzeichen enthalten.
Wenn ich die POST-Variable mit dem DB-Eintrag vergleiche, bekomme ich keine Bestätigung, dass die beiden Daten gleich sind, wahrscheinlich, weil in der POST-Variable schon dieses Fragezeichen, anstatt dem (z.B.) ü ist. Ich habe versucht per $loesung = str_replace("ü","ue",$_POST['loesung']); das Problem zu beheben, aber leider funktioniert auch dies nicht, da wahrscheinlich auch hier schon das Fragezeichen anstatt des Umlautes eingefügt wurde. Weiß jemand wie ich das ändern kann? ;)

Bestimme also eine Zeichenkodierung der Formulardaten (letzter o. g. Verweis), den Du problemlos verarbeiten kannst!

Gruß aus Berlin!
eddi

[markus_walther]

Ah...
daran hat es gelegen:
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
hab es jetzt durch folgendes ersetzt und funktioniert super:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
Dankeschön!

markus