nicht angemeldet
Hi dedlfix!
Vorab schon mal vielen Dank für deine ausführliche & hilfreiche Antwort.
Ich hatte ja schon gehofft, dass der "Fachmann" hier antwortet. ;-)
Die ereg-Funktionen sind kein Ersatz für PCRE. Das ist aber auch nicht nötig, denn PCRE kann auch in einem UTF-8-Modus arbeiten. Dazu gibt es einen Modifier.
OK, gefunden und verstanden.
Mein erstes Problem besteht jetzt schonmal darin, dass mir nicht klar ist, in welcher Kodierung denn nun bspw. ein Request (URI + Query String) auf dem Server überhaupt ankommt, wovon das abhängig ist und wie ich das feststellen kann?
Feststellen, in welcher Kodierung Daten vorliegen, kann man prinzipbedingt nicht. Man kann es höchstens erraten, solange nur wenige Kodierungen eine Rolle spielen. Man kann eine ankommende Bytefolge darauf testen, ob sie die UTF-8-Spielregeln einhält, sprich: ob die Sequenzen der Bytes größer als 0x7f regelgerecht sind. Aber da jegliche Bytefolge auch gültiges ISO-8859-1 sein kann, ist eine eindeutige Erkennung schon daran zum Scheitern verurteilt. Lediglich am interpretierten Inhalt kann man erkennen, ob etwas Sinnvolles rauskommt oder nicht.
Die Problematik leuchtet mir ein, wenngleich das eine praktische Umsetzung ja irgendwie nicht gerade erleichtert.
Alle Funktionen, die dir eine Zeichenkodierungserkennung versprechen, kochen auch nur mit Wasser und liefern nicht in jedem Fall ein fehlerfreies Ergebnis.
Überhaupt scheint das ein "schwieriges" Kapitel zu sein. In den diversen User-Kommentaren zu einigen der PHP-Funktionen liest man immer das Wort "buggy" ...!
Es ist auch nicht möglich, einem Client die zu verwendende Kodierung vorzuschreiben. Das geht schon deshalb nicht, weil ein Client auch ohne den Server zu kennen, eine Anforderung absenden können muss. Weiterhin gibt es keine Regel, in welcher Kodierung er zu senden hat und auch keinen Header oder dergleichen, in dem der Client dem Server die verwendete Kodierung mitteilt.
Ja, klasse. Je mehr ich mich mit dem Thema (zwangsweise) befasse, umso erstaunter bin ich, dass das Surfen im Web bisher so "unproblematisch" funktioniert hat.
Dies stellt aber in der Praxis nicht unbedingt ein Problem dar. Initiale Requests kommen oft mit den ASCII-Zeichen aus. Formulardaten werden vom Client in der Regel in der Kodierung abgesendet, die die das Formular enthaltene Seite deklariert hat. Das accept-charset-Attribut eines Formulars trifft hingegen in der Praxis nicht selten auf taube Ohren.
Kommen die Daten in der URL an, so besteht die Möglichkeit, dass sie ein Mensch eingetippt hat und der Request ein initialier ist. Der Browser verwendet dann seine Default-Einstellung, ohne das dem Server mitteilen zu können. Du kannst nur versuchen, ob die Daten gültiges UTF-8 sind, und wenn nicht, sie von ISO-8859-1 nach UTF-8 umzukodieren und dann zu versuchen, ein Ergebnis für diesen Request zu finden.
Hier fangen dann meine Probleme an. Denn welche Funktion muss ich denn nun bspw. verwenden: stripos() (für ISO-8859-x) oder mb_stripos() (für UTF-8)?
Und es fängt ja schon viel früher an. So ist mir u.a. auch noch nicht klar, wann, wie und warum welcher Browser in der Adresszeile "Klartext" (auch mit Umlauten etc.) und wann URL kodierten Text (also mit %xx) anzeigt? Mein FF 3.5 zeigt bspw. bei einem Klick auf einen Link den "Klartext" in der Adresszeile (in der Statuszeile ebenso) an und bei manueller Eingabe den kodierten Text.
Lasse ich mir dann bspw. per Script die $_SERVER Variablen anzeigen, dann sind $_SERVER[REQUEST_URI] und $_SERVER[QUERY_STRING] immer kodiert, während $_SERVER[PATH_INFO] im Klartext angezeigt wird.
Beispiel:
$_SERVER[REQUEST_URI]: /Umlaute:%20%C3%A4%C3%84%C3%B6%C3%96%C3%BC%C3%9C%C3%9F%20Preis:%20%E2%82%AC%2030,-
$_SERVER[PATH_INFO]: /Umlaute: äÄöÖüÜß Preis: € 30,-
Für die UTF-8-"Erkennung" gibt es einige Funktionen in den Userkommentaren bei den üblichen verdächtigen Funktionen (suche bei utf8_decode, utf8_encode, mb_detect_encoding). Sie können aber lediglich die formale Richtigkeit von UTF-8-Sequenzen ermitteln, nicht aber, ob tatsächlich eine UTF-8-Kodierung vom Autor beabsichtig war oder ob die Bytesequenz nur zufällig gültiges UTF-8 ergibt.
Ja, danke! Mit den ganzen Funktionen komme ich auch noch nicht wirklich zurecht. Solange ich die_nicht_verwende, funktioniert bisher alles (augenscheinlich) wie es soll. Sobald ich mit einer der Funktionen anfange "rumzudoktern", klappt nichts mehr!
Übrigens, den Request allein im Hinblick auf UTF-8-Fähigkeit zu beachten, ist oft noch nicht ausreichend. Auch das Speichern der Daten verlangt eine Betrachtung und damit die dafür verwendeten Medien (Dateien oder Datenbanken). Du kannst ja mal aufzählen, welche Stellen dir im Webumfeld einfallen, an denen eine Zeichenkodierung eine Rolle spielt und eingestellt werden kann. Wir™ schauen dann mal, ob du alle kennst. (Das Nachschlagen im hiesigen Archiv ist nicht nur nicht verboten, sondern ausdrücklich erwünscht :-)
Ja wie jetzt? Gibt es denn noch mehr, als die, die du in deinem Artikel genannt hast? Dann wäre der ja unvollständig. ;-)
Ein Aufruf von mb_internal_encoding() gibt mir ISO-8859-1 als interne Kodierung aus.
Diese müsste ich, wenn ich durchgehend mit UTF-8 arbeiten will, dann entsprechend umstellen?Diese Frage konnte das PHP-Handbuch nicht klären?
Nein, nicht wirklich. Außerdem müsste ich doch dann nach meinem bisherigen Verständnis sicherstellen, dass meine zu verarbeitenden Strings und Arrays auch wirklich alle definitiv UTF-8 kodiert sind, oder nicht? Ansonsten würde ich ja wiederum "falsche" Ergebnisse bekommen?
Stellt sich für mich aber gleich die nächste Frage: Lohnt sich der "Aufwand/ Aufstand" (bei PHP < 6), oder wäre es ggf. sinnvoller/ einfacher, vorhandene Strings in UTF-8 in ISO-8859-1 umzukodieren, diese intern dann "normal" zu verarbeiten und vor einer Ausgabe ggf. wieder in UTF-8 zu kodieren?
Wenn ja, wie stelle ich das so an, dass ich keine Datenverluste/ -verfremdungen erleide und worauf muss ich ggf. achten?Diese Anforderung kann mit dem Ansinnen, alles nach ISO-8859-1 umzukodieren, nicht erfüllt werden. Mit der ISO-8859-Familie sind jeweils nur 256 Zeichen darstellbar. Mit Unicode hingegen können derzeit 1.114.112 Zeichen repräsentiert werden. Eine verlustfreie Umkodierung kann nur dann stattfinden, wenn nur die 256 ISO-8859-x-Zeichen verwendet werden.
Du hast natürlich Recht, dass ein Umkodierung nur von einem Zeichensatz A auf einen Zeichensatz B Sinn macht, wenn B mind. auch alle Zeichen von A beinhaltet.
Ob sich der Aufwand lohnt, musst du selbst entscheiden, denn nur du kennst die Anforderungen deines Projekts.
Der Aufwand ist mir eigentlich egal - zuverlässig funktionieren soll es. ;-)
Hierzu bräuchte ich wirklich mal einen guten Rat, welches die sinnvollste Vorgehensweise ist.
Anforderung ist im Prinzip "nur", dass aufgrund meiner "sprechenden" URLs eben auch Umlaute korrekt gehandhabt werden können sollen (tolles Satzkonstrukt). Dabei war ich wohl fälschlicherweise davon ausgegangen, bzw. dem Trugschluss erlegen, dass wenn ich eh alles andere UTF-8 kodiere, es dann auch "einfacher" wäre, scriptintern gleich mit UTF-8 kodierten Strings und Arrays zu arbeiten. Dem scheint aber wohl momentan zumindest noch nicht so zu sein.
(leicht verwirrter)
Gruß Gunther