Problem mit GeSHi und dem großen "Ü"

[Matze]

Hallo zusammen,

ich habe bei der Verwendung von GeSHi ein seltsames Problem. Im gehighlighteten Code (und nur dort) wird das große "Ü" falsch dargestellt. Es sieht so aus, als würde etwas mit der Kodierung nicht stimmen, doch da die anderen Umlaute funktionieren, kann ich mir das nicht erklären. Im Anhang ist ein Screenshot und falls es relevant sein sollte, hier der Link zu einer Beispielseite

Bis zu dieser Zeile stimmt alles, doch diese verursacht das Problem:

Code:

return utf8_encode($geshi->parse_code($source, $code_lang));

Ohne utf8_encode() werden die Umlaute alle falsch dargestellt. Da nützt auch ein

Code:

$geshi->set_encoding('UTF-8');

nichts.

Habt ihr eine Idee, was die Ursache für das Problem sein könnte?

Ein schönes Wochenende wünscht
Matze

[marabu]

Hallo Matthias,

für mich gibt es da nur eine Erklärung: Du hast die Datei nicht in einem Rutsch geschrieben und mittendrin den Editor gewechselt. Dabei ist eine falsche Kodierung für das Ü verbaut worden, die beim nächsten Speichern mit einem UTF-8 Editor durch die Sequenz "EF BF BD C2 9C" als Marker für Nonsense ersetzt wurde. Du solltest die beiden Marker-Zeichen löschen und mit einem Editor deines Vertrauens das gewünschte Ü eintragen.

Freundliche Grüße

[Matze]

Hallo Achim,

seltsam ist jedoch, dass es in der Datenbank korrekt eingetragen ist. Mit PhpMyAdmin beispielsweise sehe ich das "Ü" richtig und wenn ich es damit entferne, neu einfüge und eintragen lasse, sehe ich weiterhin dieses ungewollte Zeichen.

Grüße

[marabu]

Hast du es mit einem Hex-Editor überprüft?

Das große Ü müsste als C3 9C kodiert sein.

Kannst du den Text aus der Datenbank anhängen?

[Matze]

Hallo Achim,

ich hoffe, ich habe das nun korrekt exportiert.
Das "Ü" ist als "DC" eingetragen. Im Anhang der Datensatz.

Grüße

[marabu]

Hallo Matthias,

da ist irgend etwas nicht koscher. DC ist der Code für das große Ü im ISO Latin-1 Zeichensatz, C3 9C ist die Kodierung in UTF-8.
Es sieht so aus, als ob du einen Latin-1 kodierten Text einem UTF-8 deklarierten Feld untergeschoben hast.
Du solltest deine Routinen überprüfen, die für das Abspeichern zuständig sind.

Gute Nacht

[Matze]

Hi Achim,

ich denke nicht, dass ich den Datensatz falsch in die Datenbank einfüge. Denn wenn ich ein "Ü" außerhalb der GeSHi-Tags verwende, wird es korrekt dargestellt. Wenn ich statt

Code:

return utf8_encode($geshi->parse_code($source, $code_lang));

das zurückgebe:

Code:

return $source;

dann wird auch alles korrekt angezeigt. Wenn ich den Text direkt in PhpMyAdmin eingebe, dann muss die Kodierung eigentlich auch stimmen. Der Fehler tritt wirklich nur auf, sobald ich den Text durch GeSHi hervorheben lasse.
Wenn ein Kodierungsfehler vorliegen sollte (und wenn, dann müsste es an GeSHi liegen, "normaler" Text funktioniert ja), dann würden auch alle Umlaute fehlerhaft dargestellt werden, doch das ist nur beim großen "Ü" der Fall. Daher finde ich das so seltsam.

Nachtrag: Ich habe festgestellt, dass die Problematik bei ÄÖÜ und ß auftritt, hingegen äöü werden korrekt dargestellt.

Grüße,
Matze

[BenBE]

GeSHi gibt bereits UTF8-Kodiert seinen Inhalt zurück. Also kein Grund, dass noch mal utf8-zu encodieren.

BTW: set_encoding wird ignoriert. Als Input-Encoding wird immer UTF8 angenommen, bzw. anders ausgedrückt: Alles >=128 wird unverändert durchgewunken.

[Matze]

Guten Morgen Benny

Zitat von BenBE:

GeSHi gibt bereits UTF8-Kodiert seinen Inhalt zurück. Also kein Grund, dass noch mal utf8-zu encodieren.

Danke für den Tipp. Durch diesen bin ich darauf gekommen, dass ich an einer Stelle html_entity_decode() nutze und dass es daran liegen muss. Wenn ich vor dem Funktionaufrud fie HTML-Zeichen (Ä ...) durch die uncodierten Zeichen ersetze geht es nun.
Ich muss noch genau testen, ob Sicherheitslücken ausgeschlossen sind, aber es sieht so aus, als würde das zuverlässig funktionieren.

Im Endeffekt lag's also gar nicht direkt an GeSHi, sondern an der Vorbereitung des zu highlightenden Codes.

Es grüßt
Matze

[BenBE]

Das ist meist so. Grad solche Fehler, dass einzelne Zeichen falsch dargestellt werden, werden häufig durch einen Fehler bei der Zeicheneingabe ausgelöst. Auch beliebt ist immer strip_slashes NACH dem Aufruf von GeSHi auszuführen und sich dann zu wundern, warum der gesamte Quelltext ein String ist

Bzgl. den Escapes von HTML: Alles was irgendwie gefährlich ist (oder beim Verarbeiten stört) wird mit einer abgewandelten htmlspecialchars-Funktion escaped (Alte PHP-Versionen hatten da mal nen Bug, der Code-Execution zuließ). Zudem dient die Escapes bei GeSHi intern zur Markierung von von bereits hervorgehobenen Dingen. Der einzige Angriff wäre also möglich, wenn man dem User die Möglichkeit gibt, JEGLICHES CSS anzugeben. Das ist aber ein Problem der Vorgehensweise und hier kann der Anwender wesentlich besser agieren, als GeSHi, da man > niccht per-se filtern kann in CSS (Hat dort nämlich durchaus Berechtigung).