strtolower niemals nutzen, veraltet?

[dedlfix]

Tach!

mir fiel ein seltsames Verhalten bei strtolower() auf. [...] Daraus wird, obwohl alles UTF-8, dieses:

Nicht obwohl, sondern weil. Die Stringfunktionen von PHP sind nur auf Ein-Byte-Kodierungen ausgelegt. Sie stammen aus einer Zeit, bevor Unicode/UTF-8 populär wurde und sind seitdem nicht mehr angefasst worden. Zum einen hätte man recht viele Inkompatibilitäten in PHP gebracht, zum anderen stellte sich der Umstellungsversuch als sehr schwierig heraus. Deswegen ist auch Version 6 gescheitert, und Version 7 hat immer noch keine durchgängige Unicode-Unterstützung an Bord.

Nun weiss ich zwar, dass strtolower keine Umlaute umwandeln kann, hatte aber erwartet, dass diese dann dennoch normal erscheinen.

Du hast da wohl einen Fehler im Versuchsaufbau. Die betroffenen Umlaute sind ja bereits Kleinbuchstaben, da hätte weder strtolower() noch mb_strtolower() etwas zu tun gehabt. Ich kann das Fehlerbild nur nachvollziehen, wenn der PHP-Code und somit das Stringliteral gemäß ISO-8859-1 kodiert ist und dem Browser gesagt wird, es käme UTF-8, beispielsweise durch die ini-Direktive default_charset.

Gib doch mal vor und nach dem strtolower() die Strings mit echo urlencode($str); aus. Damit sieht man die Kodierung der Umlaute sehr einfach.

Nun stelle ich mir aber die Frage, wie schnell ich mir Probleme damit einhandeln könnte,

Die bekommst du, wenn du dir über Zeichenkodierung zu wenig Gedanken machst. Prinzipiell muss zum einen ein verarbeitendes System mit der verwendeten Kodierung umgehen können, zum andern muss ein Nachfolgesystem die verwendete Kodierung mitgeteilt bekommen. Und die Zeichen müssen dementsprechen korrekt kodiert sein. Der Teufel steckt im Detail, wie man das den jeweiligen Systemen einzustellen beziehungsweise mitzuteilen hat.

Im Manual habe ich dann in den Kommentaren eine Funktion gefunden, die das ändert aber auch schon uralt ist und zudem den Nachteil hat, dass man auch alles damit konvertieren muss,

Die ist nicht alt, sondern prinzipbedingt nicht für alle Situationen geeignet, auch damals schon nicht. utf8_decode() muss alle Zeichen verwerfen, die in der Zielkodierung ISO-8859-1 nicht enthalten sind. Das kann man nur dann anwenden, wenn keine Zeichen außerhalb des Umfangs von ISO-8859-1 verarbeitet werden.

wobei ich nicht mal getestet habe was passiert, wenn kein UTF-8 vorliegt.

Dann geht es nicht, weil das dort verwendete utf8_decode() dann für UTF-8 ungültige Byte-Sequenzen findet und diese zu einem Fragezeichen umwandelt.

Na ja, dann fiel mir ein da war ja auch eine andere Möglichkeit, mb_strtolower().

Ich vermute mal, und das ist die eigentliche Frage hier, ich sollte immer diese anstatt strtolower() verwenden, oder gibt es Ausnahmen?

Das kommt immer darauf an, wie du dein System eingestellt hast, und welche Kodierung tatsächlich vorliegt und verarbeitet werden soll. Prinzipiell ist es jedoch empfehlenswert, alles auf UTF-8 einzustellen, also angefangen von Code-Dateien über Daten-Dateien und Datenbankinhalten, gehend über die gesamte Verarbeitungskette, bis hin zu den Ausgabekanälen.

Das ist auch keine Besonderheit der Datenverarbeitung. Wenn für Lebensmittel die Verarbeitung falsch stattfindet oder die Kühlkette unterbrochen wird, entsteht unter Umständen auch ein unbrauchbares Ergebnis.

Denn normalerweise warnt das Manual plakativ doch vor veralteten/nicht_sinnvollen Sachen, daher der Gedanke es gibt vielleicht doch manchmal Gründe strtolower den Vorzug zu geben?

Die Funktionen sind ja auch nicht an sich veraltet, sondern nur auf eine bestimmte Kodierung ausgelegt. Man kann aber sagen, dass diese ISO-8859-Kodierungen nicht mehr zeitgemäß sind.

Und wenn das so ist, auch immer mit dem Argument UTF-8 mb_strtolower($str, 'UTF-8');, oder spricht da was dagegen?

Der Aufwand. Man kann den Multibyte-Funktionen mit mb_internal_encoding() generell mitteilen, welche Kodierung es zu erwarten hat sowie verwenden soll.

dedlfix.