anpera.net

Okay, ich werd mir also einen Kaffee genehmigen und nochmal drübergehen.
Und ja, die komplette Änderung wird nicht übernommen. Man hängt quasi mit der Vorschau fest, weil man angeblich einen falschen Namen eingegeben hätte. Außer, man lässt die Sonderzeichen weg. Dann funktionierts seltsamerweise.

Screenshot gibt es hier

Und was den Page-header in der Bio betrifft: Der Fehler betrifft derzeit nur einen User, weil er Sonderzeichen in der Farbgebung seines Titels hat. Vergeben wurde der durch mich in der Grotte. Sehen tun wir aber alle "Denkt an �Br�uc�hp�ilot Hoél Yvans".

bio.php



ersetze mit:



Zur Lodge:

Gib Demras im Spiel mal bitte Donationspoints ( genügend! ) damit ich mal was probieren kann. Vom Code an sich seh ich jetzt keinen Fehler.

Mit der Änderung wird nun das ausgeworfen: Denkt an `ùBr`óuc`áhp`Àil`[o`Tt H`Aoé`yl Yvans
:/

Aber an DPs soll es Demras jetzt nicht mangeln.

Ah, die Information war gut.

logde.php, die folgenden Zeilen:



preg_replace ersetzt alle Farbcodes - spezifischer, er setzt das Byte für ` und das darauf folgende (byte). Bei multi-byte-Zeichen würde nur das erste Byte ersetzt werden... Probier mal:



Für den page_header probier das hier:



Edit: Den Ersatz-Code etwas verschönert.

(Bitte diesen Post ignorieren).

Funktioniert beides wunderbar. Ich hatte ja schon ein wenig die Hoffnung aufgegeben.
Danke!
Aber was macht das u denn konkret in diesem Fall? Also wofür steht das, wenn ich so dreist fragen darf?

Korrigier mich wenn ich falsch liege Eli.

@Waldmonster

Der Lösungsansatz von Eli behandelt Suchmuster und durchsuchte Zeichenkette als UTF-8.

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:



Angenommen, der einzige Farbcode wäre `ä, würde die Ausgabe von $appoencode_str nichts besonderes anzeigen und das Stück Code wird zu:



Was man allerdings nicht sieht, ist die Codierung. In Bytes geschrieben, würde das so aussehen:



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):



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.

Aaaah! Jetzt macht das auch Sinn.
Vielen lieben Dank an euch beiden!