PHP: htmlentities() zerstört UTF-8

htmlentities() ist ja eine Recht nette PHP Funktion um schnell das ganzen HTML aus einem String zu bekommen, weil man den z.B. (als Code) ausgeben möchte. Aber: Die Funktion macht UTF-8 kaputt! Also muss man entweder sowas wie utf8_decode(htmlentities($str)) machen, oder man schaut sich die Argumente noch mal genau an, und stellt fest, dass man das Charset auf explizit angeben kann. Diese Variante lässt UTF-8 am Leben:


htmlentities($str, ENT_COMPAT | ENT_HTML401, "UTF-8");

Ab PHP 5.4 ist das auch die Standardeinstellung, aber so modern sind wir leider noch nicht…

Kann einem ein wenig Kopfzerbrechen sparen, wenn einem das klar ist… Oder man sich wundert, warum der Vorgänger eine Funktion htmlentities8() definiert hat…

Dieser ganze Kram mit den Zeichenkodierungen ist echt nervig. Man versucht nun schon alles auf UTF-8 zu halten, aber ständig gibt es irgendwelche Funktionen, Browser oder Software bei der das nicht Standard ist, oder die man noch mal extra dran erinnern muss….

3 Gedanken zu „PHP: htmlentities() zerstört UTF-8

  1. Tja, gefunden hatte ich diesen Parameter auch. Jedoch war damit irgendetwas faul. Ich weiß gerade nicht mehr was, aber zuerst war htmlentities8 nur ein einfacher Wrapper, der das Charset gesetzt hat. Damit ging irgendetwas schief. Vielleicht irgendetwas in Benutzernamen mit asiatischen Zeichen (ja, sowas gabs mal).

    Übrigens: Wenn ihr auf eine Funktion „function s($str) { return mysql_escape_string($str); }“ stoßt… das ist NUR zum Vermeiden unnötig langer Aufrufe…

    Abgesehen davon gibt es ja so ein real_mysql_escape_string (oder so), das man bevorzugt verwenden sollte…

    1. Oh man, wer will den bitte asiatische Zeichen im Benutzernamen ?!
      Das ist natürlich ein guter Hinweis, dann bleibe ich bei deiner Methode. Das Portal steckt immer wieder voller Überraschungen 😛

      Und ja, mysql_real_escape_string SOLLTE man verwenden, ab PHP 5.3. ist das andere deprecated. Ich bin schon immer fleißig am ersetzen, wenn es mit mal über den weg läuft 🙂

  2. Im Passwort hatten wir sowas auch schon, was dann auch die vorherige Hash-Funktion verwirrt hat. In der DB sind ja zwei Passwort-Spalten. Die erste war früher einmal und wird beim Login (denn nur dann steht das Kennwort ja im Klartext zur Verfügung) in das neue Format konvertiert…

    Und WAS es alles gibt. Z.B. Hausnummern der Art „A3b“. Das hat der Validator dann nicht erlaubt…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.