Exakt.
Das Problem ist, dass die Dateien als UTF-8 gespeichert sind. Das heisst, ein "ä" besteht nun aus 2 Bytes: "C3 A4". Um alle (gültigen) Farbcodes aus einem Namen zu streichen, verwendet LotGD eine regular expression. Im folgenden Code-Zitat ist $appoencode_str eigentlich nichts mehr als eine Liste aller Farbcodes ohne Apastroph:
Code:
preg_replace("/[`][".$appoencode_str."]/", "", $regname)
Angenommen, der einzige Farbcode wäre `ä, würde die Ausgabe von $appoencode_str nichts besonderes anzeigen und das Stück Code wird zu:
Code:
preg_replace("/[`][ä]/", "", $regname)
Was man allerdings nicht sieht, ist die Codierung. In Bytes geschrieben, würde das so aussehen:
Code:
preg_replace("/[`][\xC3\xA4]/", "", $regname)
Standardgemäss behandelt preg_replace den String aber nicht als utf8. (Okay, eigentlich behandelt keine Funktion < PHP7 utf8 string als solche, ausser, man notiert es explizit. Und nicht alle Funktionen unterstützen das. strlen("ä") gibt zum Beispiel eine Länge von 2 an, mb_strlen("ä") eine von 1.) Für die RegExp schaut es so aus, als ob das 2 Farbcodes sind! Je nach Konfiguration (bzw je nach Zeichentabelle) ist der folgende Code eigentlich zutreffender (in dem Fall, ISO 8859-1):
Code:
preg_replace("/[`][ä]/", "", $regname)
Das heisst, die RegExp erkennt hier 2 Farbtags: `Ã (Vergleich das mit deinem ersten Screenshot vom Originalpost - fällt dir auf, dass du viele Farbcodes mit dem Zeichen hast? Jetzt weisst du warum!) und `¤. Aber keinen Farbtag `ä!
Der RegExp-Modifier "u" aktiviert "utf8-Verständnis" seitens der RegExp-Engine. Der RegExp versteht nun, dass C3A4 ein einziges Zeichen ist: ä, und ersetzt es dementsprechend auch richtig.