nicht angemeldet
Moin!
»» Entscheide dich für einen Zeichensatz - und bleib dabei.
Das ist das Problem. Es ist nicht meine Entscheidung, was ein Verwender nachher im Einsatz hat.
Der Verwender wird nicht in deinen PHP-Skripten herumfummeln, jedenfalls sollte er das nicht tun, oder er sollte wissen, was er tut.
Die meisten Scripte müssen sowohl auf Servern laufen, die ISO-8859-1 nutzen, als auch auf solchen, die UTF-8 benutzten.
Kein Server nutzt von sich aus das eine oder andere, ohne dass es sich ändern lässt. Genauer gesagt nutzt ein Server eigentlich gar keine Codierung, sondern liefert nur Bytes aus - und wie die im HTTP-Header getaggt sind, ist im Zweifel der PHP-Applikation überlassen, die entsprechende Header auch manuell programmiert setzen kann, um sicherzugehen, dass kein Default-Encoding dazwischenfunkt.
Man kann also in der Regel problemlos eine UTF-8-Applikation bauen, ohne sich um Server-Probleme kümmern zu müssen, wenn man sich an allen Schnittstellen mit externen Kommunikationspartnern (Browser, Datenbank, Mail) darum kümmert, korrekte Encoding-Angaben mitzuliefern.
Ich möchte die Scripte daher so absichern, dass sie sich entweder weigern, falsch eingerichet zu arbeiten oder eben besser, nach Möglichkiet auf die (Fehl-)Einrichtung reagieren, zumindest also (im Installationsmodus) gezielt Anweisung geben, was zu ändern ist.
Dein Test auf die Stringlänge von Umlauten wird immer korrekt den Zustand widergeben, der zum Zeitpunkt des Speicherns dieses Skriptes vorherrschte. Wenn du das Skript als UTF-8 speicherst, werden 6 Bytes in die Datei geschrieben, von PHP auf jedem Server der Welt auch als 6 Bytes wieder erkannt, und deshalb ist strlen() dann immer 6.
Daran ändert sich auch nichts, wenn ein unbedarfter PHP-Programmierer die Datei in einem ISO-8859-1-Editor öffnet, und irgendwo anders falsche Umlaute einfügt. Denn der String ganz oben wird dann ja als 6 "unleserliche" ISO-Zeichen angezeigt und wieder abgespeichert - und der Check auf strlen() ändert sich gar nicht.
Erst wenn der Bearbeiter die Datei tatsächlich umcodiert, würde der Check in die andere Fallunterscheidung laufen. Aber wer wird sowas idiotisches tun, ohne sich selbst für die Konsequenzen verantwortlich zu machen?
- Sven Rautenberg