• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Defekte Umlaute / Sonderzeichen im Forum

Hallo!

Unter Umständen konnte das Problem gelöst werden. Ihr könntet bei Gelegenheit nochmals testen, ob Umlaute / Sonderzeichen nach dem Timeout / Logout jetzt korrekt dargestellt werden. Die Cookie-Timeout Zeit ist wieder auf den Standardwert von 900 Sekunden eingestellt.

mfG
Thorsten
 
test äöüß°^§฿
冬が来ています。

/Edit: Funktioniert, Danke Thorsten
 
Hallo!
Es liegt definitiv am Server. Ich denke mal, dass Joe mit seiner Vermutung richtig liegt.
Das war kein Server Problem. Siehe angehängte Patch Datei.

mfG
Thorsten
 

Attachments

  • postvars_utf8.patch.txt
    2.1 KB · Views: 306
Ok, die Applikation. Wollte nur meinen geliebten Browser verteidigen :-D
Jetzt tun meine Augen weh, der PHP Code sticht ja mit seinen Dollarzeichen förmlich das Auge aus. Jetzt bin ich blind. :eek:


Jetzt der Hardcore-Test:

☢❤☭☢❤☭������

Die funktionieren nicht: https://unicode-table.com/de/1F607/
 
Last edited by a moderator:

Attachments

  • emoji.png
    emoji.png
    8.4 KB · Views: 299
Last edited by a moderator:
Nach dem POST-Request verschwinden die Zeichen. Habe es beim ersten mal so direkt gepostet. Dann nochmal bearbeitet und durch andere Zeichen ersetzt, die auch nicht dargestellt werden.

Komischerweise steht mein Firefox auf dieser Seite jedes mal auf Westlich.

Code:
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
Type 'copyright', 'credits' or 'license' for more information
IPython 6.0.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import unicodedata

In [2]: unicodedata.unidata_version
Out[2]: '8.0.0'

In [3]: unicodedata.lookup('Smiling Face with Halo'.upper())
Out[3]: ''

PHP ist einfach schlecht :-D
Ich denke mal der Fehler liegt irgendwo zwischen Webserver-PHP-Code, vielleicht auch die Datenbank.

Ich schau mir jetzt mal an, wie der POST-Request aussieht. Ich poste ihn dann auch nochmal.

EDIT: Beitrag geändert
 
Last edited by a moderator:
Ja, auf einmal funktioniert es. Das nervt doch einfach nur noch!

Die beiden Bilder sind angehangen, Kopfzeilen und Parameter.
Die Unicode-Zeichen werden als HTML-Entities umgewandelt.
Scheint wohl das Verhalten des Browsers zu sein,
wenn er auf Westlich eingestellt ist oder was legt das Verhalten fest?
 

Attachments

  • Bildschirmfoto vom 2017-08-02 14-35-47.png
    Bildschirmfoto vom 2017-08-02 14-35-47.png
    43 KB · Views: 300
  • Bildschirmfoto vom 2017-08-02 14-34-58.png
    Bildschirmfoto vom 2017-08-02 14-34-58.png
    130.7 KB · Views: 290
Finde ich interessant. Wenn man HTML-Entities direkt eingibt, werden diese auch als Unicode-Zeichen dargestellt.

Probier mal selbst: '& # 128519;' ohne Leerzeichen.
 
Beitrag vor dem Bearbeiten:
PHP:
<?php
$mystring = ""; // & # 128519; ohne Leerzeichen

Beitrag nach dem Bearbeiten:
PHP:
<?php
$mystring = "��"; // & # 128519; ohne Leerzeichen
 
Siehe mein vorheriger Beitrag. Wie DeaD_EyE erwähnt hat, wird "&#128519;" im Beitrag zu Unicode umgewandelt, was nicht sehr schön ist, weil es unter anderem auch Code-Blöcke kaputt macht. Wenn man den Beitrag dann Bearbeitet, erscheinen nur zwei "Unknown-Unicode" Character und damit hat sich das ganze dann auch schon wieder selbst zerschossen.
 
Wenn ich das jetzt richtig verstanden habe, sendet der Browser UTF-8, dann ersetzt die Funktion htmlentities() Unicode durch die jeweilige XML-Repräsentation. Dann landet es irgendwann in der Datenbank, wahrscheinlich als latin1 :rolleyes:.

Eigentlich, müsste das dann auch mit dem Bearbeiten problemlos funktionieren, es seiden die PHP-Anwendung macht hier etwas unerwartetes (hin- und her-konventieren). Tut sie das?

Will man jetzt diese htmlentities posten, ohne das diese interpretiert werden, müssten diese escaped werden, da sie ansonsten wieder an einer anderen Stelle interpretiert werden. Spätestens im Browser passiert das.
 
Hallo!

Das Ganze passiert im Übrigen bei einer frischen vBulletin Installation ganz genauso. Liegt also nicht speziell an dieser (Server-)konfiguration.

mfG
Thorsten
 
Hallo!

Mit einigen Entities gibt es übrigens beim Editieren keinerlei Probleme (z.B. #10003, #10004, #10005)

✓ ✔ ✕

mfG
Thorsten
 
test für: ★☎⚡
��
↑↑↑↑ U+1F0B6 (Spielkarte) klappt nicht nach Editieren
��
↑↑↑ u+1F687 Metro
��12

Mein browser sendet das Formular laut Wnetwickler-Tool ab mit:
application/x-www-form-urlencoded; charset=UTF-8

Ignoriert eigentlich das Forum beim Speichern das charset beim Gesendeten?
 
Last edited by a moderator:
Ignoriert eigentlich das Forum beim Speichern das charset beim Gesendeten
Ja, denn das Charset der Website ist ISO-8859-1 und dieser Charset wird zudem erst spät in der HTML deklariert, letzteres mögen manche Clients nicht.
Darüberhinaus verwendet die WebApp wohl iconv zum Konvertieren (so sieht es jedenfalls gemäss dem oben geposteten Patch aus), welches weniger geeignet ist, als etwa mbstring.
Weiterhin sind auch die Charsets der Datenbank, der DB-Tabelle und der DB-Row, sowie des Transports/Handshakes relevant.
Und last but not least ist auch der Charset der Dokumente (Scripts, CSS, JS, etc.) selbst relevant.

Viele Baustellen, welche man nicht immer Alle mit vertretbarem Aufwand beseitigen kann.
Mich hat das für die von mir eingesetzten Apps sehr viel Arbeit gekostet und ich muss trotzdem noch jedes Update wieder neu patchen, bevor es produktiv geht.

Thorsten kann vermutlich nicht mehr tun, als Alles konsequent auf UTF8 umzustellen und die dann verbleibende Unicode-Inkompatibilität zu ignorieren. Das ist aber nicht in wenigen Stunden getan und erfordert viel Hirmschmalz, einige Patches und noch mehr Tests. Die grössten Probleme werden das Patchen der App(s) und die Umstellung der DB bereiten, da kann man viel falsch machen (ist mir damals 2006/2007 leider auch so ergangen).
 
Hallo!
Multybyte-Unicode wie Emojis werden gefressen!
https://xenforo.com/community/threads/how-can-i-use-unicode-characters-in-phrases.111505/ said:
Emojis are 4 byte unicode characters, which require utf8mb4 encoding to be stored in MySQL. XenForo only uses the regular utf8 encoding by default.
mfG
Thorsten
 
Back
Top