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:

$this->bbcode_second_pass_code('', '
$comp1 = strtolower(preg_replace("/[`][".$appoencode_str."]/","",$regname)); // no black, no background colors
$comp2 = strtolower(preg_replace("/[`][".$appoencode_str."]/","",$_POST['newname']));
')

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:

$this->bbcode_second_pass_code('', '
$comp1 = strtolower(preg_replace("/[`][".$appoencode_str."]/u", "", $regname)); // no black, no background colors
$comp2 = strtolower(preg_replace("/[`][".$appoencode_str."]/u", "", $_POST['newname']));
')

Für den page_header probier das hier:

$this->bbcode_second_pass_code('', '
page_header("Denkt an ".preg_replace("/[`][".$appoencode_str."]/u", "", $row['name']));
')

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:

$this->bbcode_second_pass_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:

$this->bbcode_second_pass_code('', 'preg_replace("/[`][ä]/", "", $regname)')

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

$this->bbcode_second_pass_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):

$this->bbcode_second_pass_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.

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

Hallo,

ich schon wieder.
Ich hab den Hoster gewechselt und habe nun das uncharmante Problem, dass ich bei der php.ini nur sehr wenig einstellen kann. Auch ein Gespräch mit dem Support, ob man mbstring.func_overload nicht anpassen könnte, brachte nur ein "Sorry, das geht bei uns nicht!"
Ich hab also wieder munteren Zeichensalat.
Gibt es denn eine Möglichkeit, Sonderzeichen wie â als Farbcode zu verwenden, ohne an der php.ini etwas anzupassen?

Liebste Grüße,

Waldmonster

Ja gibt es ...
mbstring.func_overload war eine Möglichkeit schnell Ergebnisse zu erzielen, in meinen Augen aber auch eine ungemein unsaubere eher was für die "faulen" (das soll kein Angriff sein )
Mittlerweile ist diese Einstellung auch als veraltet markiert und dürfte in künftigen Versionen von php entfernt werden.
Die Lösung des Problems ist daher denkbar einfach, dass was einem diese Einstellung abgenommen hat nämlich selbst durchzuführen, soll heißen, ALLE Dateien durchsuchen und die Funktionsaufrufe manuell ersetzen. Klingt erstmal nach einem Haufen Arbeit, aber mittels moderner Editoren und Suchen&Ersetzen Funktionen auch schnell erledigt.

Auszug aus der Dokumentation:
mail() -> mb_send_mail()
strlen() -> mb_strlen()
strpos() -> mb_strpos()
strrpos() -> mb_strrpos()
substr() -> mb_substr()
strtolower() -> mb_strtolower()
strtoupper() -> mb_strtoupper()
stripos() -> mb_stripos()
strripos() -> mb_strripos()
strstr() -> mb_strstr()
stristr() -> mb_stristr()
strrchr() -> mb_strrchr()
substr_count() -> mb_substr_count()
ereg() -> mb_ereg()
eregi() -> mb_eregi()
ereg_replace() -> mb_ereg_replace()
eregi_replace() -> mb_eregi_replace()
split() -> mb_split()

Okay, dann setz ich mich mal heute Abend dran.
Dankeschön!

Korrekterweise muss an dieser Stelle erwähnt werden, dass das planlose ersetzen von den Funktionen sogar zu unvorhergesehenen Ergebnissen führen kann. strlen() ist noch immer eine super Funktion, um die Byte-Länge eines Strings zu messen - während mb_strlen() die Länge in Zeichen misst. Das kann zum Problem werden, wenn eigentliche Binärdaten (In PHP sind das auch Strings) modifiziert werden sollten. LoGD macht das zum Glück nicht. Einzig bei compress_out bin ich mir nicht ganz sicher.

Und als endgültige Ergänzung: Man kann die Funktion auch manuell (auf die Datei limitiert) "aliasen":

$this->bbcode_second_pass_code('', '
<?php

use function \mb_strlen as strlen;

var_dump(strlen("Hallö"), \strlen("Hallö"));
')

Ausgabe:

$this->bbcode_second_pass_code('', '
php test.php
test.php:5:
int(5)
test.php:5:
int(6)
')

Mit "use function" kann man bestehende Funktionen maskieren, solange sie nicht mit einem \ geschrieben sind. Im oberen code ist strlen ein Alias for mb_strlen, und \strlen ist das eigentliche strlen ...