Umlaute ans Backend übertragen (shNG, fhem)

[Tom Bombadil]

wvhn Wolfram, könntest Du bei Dir bitte mal prüfen, ob in Felder vom Typ Text/Textarea eingegebene Sonderzeichen richtig abgespeichert und erneut geladen werden? Ich hab hier neuerdings ein reproduzierbares Zeichensatzproblem und will mit dieser Bitte herausfinden, ob das was spezifisches hier bei mir ist, oder ein allgemeines Problem der sV:

• über shNG-Admin wurde in ein per cache:true 'speicherbares' str-Item eingegeben: ''Zählerstände Wasser, Strom, Fernw."
• die erste Ausgabe des Items per basic-print, im basic.text und basic.textarea sehen normal aus
• sobald ich im basic.text / basic.textarea was ändere, steht nach dem nächsten Reload: "Zählerstände Wasser, Strom, Fernw."
• Prüfung im shNG Admin zeigt, dass das so jetzt tatsächlich auch im str-Item so drinsteht

Genau dieses Verhalten ist hier unter 'Situation 1' beschrieben. Erste Schnellschüsse (.htaccess & co) haben nichts gebracht. Die Visu sendet im header auf jeder Seite per default ohnehin ein korrektes <meta charset="utf-8" /> - müsste also eigentlich auch passen. Warum wird also ISO 8859-1 in ein in shNG gecachtes Item geschrieben?

Ich wollte eigentlich vorhin einen vollständigen PR zur Implementierung der 'textarea' machen, aber dieser Fehler kam mir zuvor (eher zufällig entdeckt).

/tom

[Bonze]

hab gesehen, es gibt für twig, was in dem fall auch genutzt wird, ein escaping, vl muss man das mal kontrollieren..

[wvhn]

Tom Bombadil
Da gibt es tatsächlich ein Problem zwischen smartVISU und smarthomeNG. Wenn ich den Text eingebe und speichere, wird er laut Console richtig codiert an shNG geschickt. Mit dem Update des items kommt er dann aber anders codiert zurück.

Screenshot 2022-03-11 130905.jpg

shNG sieht das allerdings etwas anders. Da kommen die Daten schon falsch an und werden noch falscher zurück geschickt:

2022-03-11 13:07:50 INFO modules.websocket 192.168.2.112:51911 sent '{'cmd': 'item', 'id': 'test.varstr', 'val': 'Testzeile für Sonderzeichen\n!"§$%&/()=?`'}'
2022-03-11 13:07:50 INFO modules.websocket visu >MONIT: '{"cmd": "item", "items": [["test.varstr", "Testzeile f\u00c3\u00bcr Sonderzeichen\n!\"\u00c2\u00a7$%&/()=?`"]]}' - to 192.168.2.112:51911

Da müssen wir uns wohl mal auf die Suche machen ...

Gruß
Wolfram

[Tom Bombadil]

Klingt erstmal auf Anhieb für mich nach einem Problem im Treiber, das bis jetzt unentdeckt geblieben ist (vermutlich hat noch nie jemand Umlaute bei {{basic.input(...,text) }} eingegeben). Wenn ich es schaffe, wühle ich mich heute Abend mal ein bisschen rein - kann aber nichts versprechen, stecke mitten in einem größeren Umzug ...

/tom

[wvhn]

io.socket.send(unescape(encodeURIComponent(JSON.stringify(data))));

EncodeUriComponent macht aus dem „ü“ ein „%C3%BC“. Und das unescape verschönert es dann zu „ü“.

[Tom Bombadil]

Das mit dem Escaping könnte ich mir ggf. noch zusammenreimen, aber wozu das Encoding ist, bleibt mir ein Rätsel - meines Wissens wird in shNG auch mit UTF-8 gearbeitet. decodeURIComponent hatte ich übrigens gestern schon erfolglos probiert; dass da auch noch zusätzlich ein Escaping rumwerkelt, da wäre ich nie drauf gekommen ...

Stellt sich die Frage, ob es nicht ein einfaches 'io.socket.send(JSON.stringify(data));' auch tun würde ...

/tom

[PatrikG]

Ihr müsst darauf achten, dass alle beteiligten Services und auch alle Dateien in denen gelesen und geschrieben werden im UTF-8 Format sind. Wenn das durchgängig der Fall ist muss nichts mehr konvertiert werden.

[Tom Bombadil]

Ihr müsst darauf achten, dass alle beteiligten Services und auch alle Dateien in denen gelesen und geschrieben werden im UTF-8 Format sind. Wenn das durchgängig der Fall ist muss nichts mehr konvertiert werden.

Danke, aber dieser Hinweis kommt mindestens 9 Jahre zu spät (siehe Datum obendrüber) ... ist nur bisher keinem aufgefallen ...
/tom

[PatrikG]

Genau genommen hat das escapen von URIs nichts mit der Sprachkodierung (UTF-8) zu tun.

Nichts desto trotz würde ich an dieser Stelle nicht escapen. Normal wird das nur verwendet, wenn ne URI (z. Bsp. für HTTP- GET) gebildet werden muss.

[Tom Bombadil]

So, ich hab's jetzt mal 'auf die harte Tour' auf dem Livesystem ausprobiert. Kurz und gut: Hier funktioniert jetzt alles, wie es soll (clear cache war nach der Änderung notwendig, Ctrl-F5 hat nicht gereicht). Umlaute gehen jetzt wunderbar.

Allerdings habe ich kein KNX, Enocean und die ganzen anderen Systeme, sondern größtenteils 'nicht mainstream' sowie selbstgestrickte Systeme im Einsatz (Trovis, Helios etc). Ich kann daher nicht sagen, wie sich das auf die Protokolle/Telegramme in anderen Drittsystemen auswirkt.

PR gegen Develop ist jedenfalls gestellt (inkl. Implementierung von 'textarea'), Tests sind 'highly appreciated'.

io.socket.send(unescape(encodeURIComponent(JSON.stringify(data))));

wurde in io_smarthomeng.js und io_smarthome.py.js ersetzt durch:

io.socket.send(JSON.stringify(data));

/tom

[wvhn]

Hab den PR gemerged in der Hoffnung auf aktive Tester.

Gruß
Wolfram

[Tom Bombadil]

Liest hier jemand von der FHEM Community mit? Dort wird ebenfalls escaped + encoded, die Änderung wäre also wohl auch dort notwendig und zu testen.

/tom

[wvhn]

Guter Punkt. Ich hab’s im fronthem-Forum mal gepostet, weil es kürzlich ein Problem von ares72 mit Umlauten bei item-Namen im Editor gab. Der bezieht die item-Namen beim Einrichten auch über den Websocket.

Warten wir mal auf Antwort, bevor wir etwas ändern.

Gruß
Wolfram

[NGem]

Grüße,

ich nutze FHEM mit der smartVISU, V3.2.0. Aktuell funktionieren Umlaute nicht sauber. Der Text geht durch, der Umlaut wird falsch interpretiert, siehe Bild.basic.input.png

Wenn Ihr mir sagt, was ich tun soll, teste ich.

[wvhn]

Hi NGem ich habe Dir schon im Fronthem Forum geantwortet. Aus meiner Sicht reicht es, die Lösung von Tom hier in #19 auch im fhem-Treiber umzusetzen (Zeile 341).

Gruß
Wolfram