Unicode zerstört Listings und Logs

[Natureshadow / König Moderig]

Moin zusammen,

leider musste mir auffallen, dass bei der Verwendung von Unicode-Zeichen gerne mal das Log oder Listing verschwindet.

Gemerkt habe ich das, als ich einem längeren Log, das ich geschrieben habe, durch Editieren noch ein Smiley (☺ ← dieses da) anfügen wollte. Beim Absenden verschwand mein ganzer Log.

Ich habe dasselbe auch mit einem Listing versucht. Smiley oder anderes Unicode-Zeichen rein, weg.

Das wird mir nachher nochmal gewaltig auf die Füße fallen, da ich ein Listing von GC.com kopieren werde, das als Teil des Rätsels (durchaus nicht unübliche) Unicode-Zeichen enthält.

Was kann man machen, damit das funktioniert? Oder warum funktioniert das eigentlich nicht?

Cheers,
Nik

[pjacobi]

Ich wollte schon sagen, dass das gar nicht sein kann. Und hatte bei einem unveröffentlichtem Listing von mir testweise "Deinen" Smiley erfolgreich eingefügt.

Aber mit U+1F631 -- einem Smiley aus dem neueren, größeren Vorrat, erfuhr ich auch den Verlust der Beschreibung. Vielleicht sind es Zeichen außerhalb der BMP (der ersten 65536 Zeichen) von Unicode?

Hier im Forum werden diese Zeichen anscheinend auch abgewiesen, U+1F631 ist das "Der Schrei" Emoji (Liste: http://apps.timwhitlock.info/emoji/tables/unicode).

[dl6hbo]

Für unsere Webseite haben wir einen HTML-Purifier, der unerwünschte Dinge aussortiert.  Wie radikal er dabei vorgeht, habe ich nicht untersucht.  Dazu könnte eventuell following etwas sagen.

[mic@]

[quote="dl6hbo"]Für unsere Webseite haben wir einen HTML-Purifier, der unerwünschte Dinge aussortiert.[/quote]

Meinst Du das hier? http://www.opencaching.de/articles.php?page=htmltags

[pjacobi]

[quote="dl6hbo"]
Für unsere Webseite haben wir einen HTML-Purifier, der unerwünschte Dinge aussortiert.  Wie radikal er dabei vorgeht, habe ich nicht untersucht.  Dazu könnte eventuell following etwas sagen.
[/quote]

HTML-Purifier schön und gut, aber er sollte dann das Unerwünschte wegschmeißen, und nicht den ganzen folgenden Text auch.

Außerdem handelt es sich nicht um Markup sondern um Text, der hier zum Schluckauf führt.

Außerdem² wäre eine Warnung und zurück zum Eingabefenster hilfreicher als kommentarloses Löschen....

Ich denke aber, dass es werder Absicht ist, noch unbedingt der HTML-Purifier, sondern ein schlichter Fehler in einer der verwendeten Komponenten.

[following]

@natureshadow
Selbstverständlich kann man Unicode-Zeichen in Listings und Logs eingeben. Wenn das bei dir nicht funktioniert, dann ist dein Web-Browser defekt.

Was ich allerdings nachvollziehen kann ist dies:

[quote="pjacobi"]
Aber mit U+1F631 -- einem Smiley aus dem neueren, größeren Vorrat, erfuhr ich auch den Verlust der Beschreibung. Vielleicht sind es Zeichen außerhalb der BMP (der ersten 65536 Zeichen) von Unicode?
[/quote]

Zeichen aus den Planes > 0 verursachen anscheinend Probleme. Es liegt weder am Editor noch am HTML-Purifier (oder zumindest nicht nur daran), denn das Problem tritt auch auf wenn man den Text-Eingabemodus verwendet. Sieht so aus, als käme MySQL/MyISAM/UTF8 nicht damit zurecht, also beim Speichern in die Datenbank geht's verloren. Mag mal jemand weiter recherchieren? Auch im Hinblick auf die bevorstehende Umstellung auf MariaDB? Man könnte auf eine andere Engine als MyISAM umsteigen, wenn's daran liegt.

[Natureshadow / König Moderig]

Das Problem ist noch ein wenig gravierender.

Erstmal: Richtig, ein ☺ funktioniert. Das war ein Irrtum, mein Android macht daraus offenbar nochmal was anderes…

Aktuell geht es bei mir um das Zeichen U+1F4F1. Das sit ein kleines Mobiltelefon und wichtiger Bestandteil des Mystery-Caches, den ich gerade publizieren will.

Wenn man dieses Zeichen nun unterbringen will, passiert eins von zwei Dingen:

Wenn man ein Plaintext-Listing baut, verschwindet das gesamte Listing - ärgerlich, aber unspannend.

Wenn man ein HTML-Listing baut, dann knallt es anscheinend tatsächlich im Postprocessing des HTML, und das geht dabei dann gehörig kaputt. Den "Erfolg" sieht man hier: [1] - das Listing wurde an dem Zeichen abgeschnitten und nach Ermessen des Codes um schließende HTML-Tags ergänzt, das Resultat ist aber ungültiges und kaputtes HTML, das das gesamte restliche Seitenlayout zerstört.

Es würde mich nicht wundern, wenn an dieser Stelle eine HTML-Injektion am Parser vorbei udn damit möglicherweise auch JavaScript-Injektion möglich wäre.

Übrigens habe ich es auch mit einem HTML-Entity und dem Dezimal-Äquivalent versucht - selbes Ergebnis, auch das bricht den Parser.

-nik

[1] EDIT: Damit ich das Listing weiter bearbeiten kann, im Anhang für die Nachwelt festgehalten.

[Natureshadow / König Moderig]

Das Problem liegt - wo ich gerade nachelse - natürlich an UTF-8 vs. UTF-16. Hätte ich auch drauf kommen können…

Support für UTF-16 gibt es erst in MySQL 6 - welche Version haben wir momentan?

Allerdings erklärt das nicht, wieso ein HTML-Entity den selben Effekt auslöst.

-nik

[following]

Das Problem liegt - wo ich gerade nachelse - natürlich an UTF-8 vs. UTF-16. Hätte ich auch drauf kommen können…

Mit UTF-8 kann man sämtliche Unicode-Zeichen codieren; UTF-16 wird nicht benötigt. Der UTF-8-Code des Mobiltelefon-Symbols U+1F4F1 lautet z.B. F0 9F 93 B1.

Wenn man ein HTML-Listing baut, dann knallt es anscheinend tatsächlich im Postprocessing des HTML, und das geht dabei dann gehörig kaputt.

Negativ, der HTML-Code bleibt beim Postprocessing intakt.

[Natureshadow / König Moderig]

[quote="following"]

Negativ, der HTML-Code bleibt beim Postprocessing intakt.
[/quote]

Blöde Frage, aber ... Dann sieht OC immer so aus wie in meinem Screenshot?

Ich bin nicht der Ansicht, dass daran noch etwas intakt ist.

[following]

Das Listing wird nicht durch das HTML-Postprocessing zerschossen sondern anschließend beim Speichern in die Datenbank. MySQL < 5.5 unterstützt - wie ich gerade festgestellt habe - nur die BMP (Unicode bis 0xFFFF); bei anderen Zeichen wird der Text offenbar abgeschnitten; dadurch wird der HTML-Code zerstört.

Mit dem bevorstehenden Serverumzug steigen wir auf MariaDB 5.5 um, das entspricht MySQL 5.5 und sollte das Problem beheben. Solange wirst du dich noch gedulden müssen.  Oder du bindest das Symbol als Grafik in das Listing ein -- das ist ohnehin sicherer, weil diese Spezialzeichen nicht in jeder Schriftart vorhanden sind und somit unter ungünstigen Umständen gar nicht darstellbar sind.

[Natureshadow / König Moderig]

[quote="following"]
Das Listing wird nicht durch das HTML-Postprocessing zerschossen sondern anschließend beim Speichern in die Datenbank. MySQL < 5.5 unterstützt - wie ich gerade festgestellt habe - nur die BMP (Unicode bis 0xFFFF); bei anderen Zeichen wird der Text offenbar abgeschnitten; dadurch wird der HTML-Code zerstört.[/Quote]

Ja, nein, fast. Auf jeden Fall *versucht* etwas, das HTML zu schließen, da tauchen nach dem Zeichen noch schließende Tags auf. Oder macht OC das, wenn das Listing zum Bearbeiten geladen wird?

[quote="following"]
Mit dem bevorstehenden Serverumzug steigen wir auf MariaDB 5.5 um, das entspricht MySQL 5.5 und sollte das Problem beheben. Solange wirst du dich noch gedulden müssen.  Oder du bindest das Symbol als Grafik in das Listing ein -- das ist ohnehin sicherer, weil diese Spezialzeichen nicht in jeder Schriftart vorhanden sind und somit unter ungünstigen Umständen gar nicht darstellbar sind.
[/quote]

OK, das bedeutet aber, dass der Purifier vorher läuft und somit Infektionen als Folge ausgeschlossen sind.

Das mit dem Bild geht nicht so richtig. Das Unicode ist Teil des Mysreries (indirekt). Und das Layout ist nicht so einfach, weil der Purifier (diesmal wirklich) alle width und height-Attribute sowie width und height aus style-Attributen strippt.

-nik

[following]

[quote="Natureshadow / König Moderig"]
Ja, nein, fast. Auf jeden Fall *versucht* etwas, das HTML zu schließen, da tauchen nach dem Zeichen noch schließende Tags auf. Oder macht OC das, wenn das Listing zum Bearbeiten geladen wird?
[/quote]

Oops, da läuft tatsächlich der HTML-Purifier drüber wenn die Cachebeschreibung zum Bearbeiten geladen wird. Das ist ein Bug der sich hier eingeschlichen hatte; wird gleich korrigiert.

[following]

Zwischenstand: Die neue Serverkonfiguration mit MariaDB 5.5 und vollem Unicode-Zeichensatz (charset 'utf8mb4') ist erfolgreich getestet. Innerhalb der nächsten zwei Wochen stellen wir auf den neuen Server um, und dann wird Unicode voll zur Verfügung stehen.

Ich rate trotzdem davon ab, solche Unicode-Spezialzeichen wie das Mobiltelefonsymbol zu verwenden. Es gibt Tools, die damit nicht klarkommen. Unten hänge ich mal eine GPX-Datei zum testen an, mit einem Mobiltelefonsymbol in der Kurzbeschreibung, in der Beschreibung und im ersten Log. Wenn man die in GSAK (Version 8.1) einliest gehen die Spezialzeichen verloren ...

[ra_sch]

In c:geo wird es auch nicht dargestellt. Ob es allerdings daran liegt, ob das Zeichen nicht in der Schriftart enthalten ist, oder ob es verloren geht, muss ich noch genauer untersuchen.