Umlaute ans Backend übertragen (shNG, fhem)

[NGem]

Grüße,

ich habe das Ergebnis schon im FHEM-Forum gepostet.
https://forum.fhem.de/index.php/topi...tml#msg1214189

Können wir hier am FHEM-Treiber noch etwas testen? Jemand eine Idee?

error malformed UTF-8 character in JSON string

Was habe ich gemacht:

Änderung im smartVISU-FHEM-Treiber

io.socket.send(unescape(encodeURIComponent(JSON.st ringify(data))));

auf

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

Es kommen kein Texte mit Umlauten mehr an. Im FHEM-LOG steht dann folgender Fehler

ipc fronthem:127.0.0.1:46348 (ws): error malformed UTF-8 character in JSON string, at character offset 134 (before "\x{fffd}}") at ./FHEM/01_fronthem.pm line 250.

[Tom Bombadil]

Kenne mich mit FHEM überhaupt nicht aus - aber dass nach der Änderung immer noch Zeichen wie "\x{fffd}" übertragen werden, halte ich für eher ungewöhnlich, da jetzt nicht mehr encoded/escaped wird.

Hast Du mal den SV-Cache händisch über die Settings-Seite gelöscht? (bei mir lief es im Zusammenspiel mit shNG auch erst danach - Ctrl+F5 im Browser reicht nicht)

/tom

[wvhn]

Ich habe das im fronthem-Forum nicht weiter diskutiert, weil herrmannj ja geschrieben hatte, dass die Unterstützung von Umlauten in fhem eh gerade überarbeitet wird.

Und in fronthem steht das auch noch als offener Punkt

#open:
# UTF8 conversation

Ich fürchte, das muss erst in fhem / fronthem angepasst werden, bevor man per UTF-8 auf dem Websocket kommunizieren kann.

Gruß
Wolfram

[Tom Bombadil]

Stichwort 'UTF8 conversion': Was läuft denn auf der frontfhem-Seite, wenn nicht UTF-8? ISO 8859? Für den sV-Treiber kann man ja die Übergabe entsprechend den 'Wünschen' der Gegenseite gestalten - die richtige Zeile haben wir ja schon am Wickel ...

/tom

[NGem]

Ich würde gern den Faden nochmal aufgreifen.
Was kann ich tun/testen, damit wir fronthem, den FHEM-Treiber oder was immer befähigen, Umlaute durchzulassen?

Vielleicht nochmal zur Situation:
mit jetzigem FHEM-Treiber

io.socket.send(unescape(encodeURIComponent(JSON.st ringify(data))));

Von FHEM in Richtung smartVISU, geht es.
in Richtung smartVISU.png

In Richtung FHEM, geht es nicht. fronthem beendet sich sogar. FHEM muss neu gestartet werden.

ipc fronthem:127.0.0.1:60336 (ws): ws ipc decoding error malformed UTF-8 character in JSON string, at character offset 130 (before "\x{fffd}}") at ./FHEM/01_fronthem.pm line 818.
fronthem: thread ws closed for unknown reason
fronthem: client xyz: forced disconnect

Die Zeile 818:

$msg = decode_json($msg);

mit der geänderten Zeile im FHEM-Treiber

io.socket.send(JSON.st ringify(data));

Von FHEM in Richtung smartVISU, geht es ebenfalls.

In Richtung FHEM, geht es nicht. fronthem beendet sich in diesem Fall nicht.

ipc fronthem:127.0.0.1:33516 (ws): error malformed UTF-8 character in JSON string, at character offset 156 (before "\x{fffd}") at ./FHEM/01_fronthem.pm line 250. decoding ipc msg {"connection":"conn-fEFJRpbS","sender":"192.168.xxx.xxx","identity":"unk nown", "message":{"cmd":"item","id":"Test","v al":"Umlaut in Richtung FHEM �"}}

Die Zeile 250:

$up = decode_json($msg);

[Tom Bombadil]

Dein Wert "Umlaut in Richtung FHEM �" (vorher: \x{fffd}) weist darauf hin, dass die sV jetzt korrekt UTF-8 sendet. Das Problem liegt also offensichtlich auf der Empfängerseite, und dafür hat Dir Wolfram schon die Antwort gegeben:

Ich habe das im fronthem-Forum nicht weiter diskutiert, weil herrmannj ja geschrieben hatte, dass die Unterstützung von Umlauten in fhem eh gerade überarbeitet wird.

Und in fronthem steht das auch noch als offener Punkt

#open:
# UTF8 conversation

Ich fürchte, das muss erst in fhem / fronthem angepasst werden, bevor man per UTF-8 auf dem Websocket kommunizieren kann.

Vermutlich ist es keine große Sache, $msg aus dem von der sV empfangenen UTF-8 vor dem decode_json in was_auch_immer_fronthem_verwendet umzucodieren:

$up = decode_json($msg)

Darüber solltest Du aber mit jemandem reden/schreiben, der fronthem sowie die verwendete Programmiersprache kennt und FHEM auch im Einsatz hat. Deine Anfrage ist unter forum.fhem.de vermutlich besser aufgehoben. Bei mir ist es schon allein daran gescheitert, Deine oben aufgeführte Zeile 250 im offiziellen Repo auf Anhieb zu finden ...

/tom

[NGem]

Stichwort 'UTF8 conversion': Was läuft denn auf der frontfhem-Seite, wenn nicht UTF-8? ISO 8859? Für den sV-Treiber kann man ja die Übergabe entsprechend den 'Wünschen' der Gegenseite gestalten - die richtige Zeile haben wir ja schon am Wickel ...

/tom

Ich hatte dachte, wir verfolgen diese Spur vielleicht.

Aber Du hast natürlich Recht. Es wäre besser fronthem zu befähigen UTF8 zu können.

[Tom Bombadil]

Wie schon geschrieben - es fehlen mir (und vermutlich den meisten anderen hier auch) einfach Kenntnisse über Perl, FHEM und fronthem.

Sofern auf FHEM-Seite Umlaute komplett unterstützt werden (dazu habe ich bei einem kurzen Querlesen im FHEM-Forum widersprüchliche Aussagen gefunden - von geht nicht über geht teilweise bis zu geht nur in Variablennamen, aber nicht in Werten), musst Du für die Kommunikation nur sicherstellen, dass Sender und Empfänger dieselbe Codierung verwenden. Welcher Zeichensatz dabei verwendet wird (UTF-8, ISO8895, Plain ASCII, was_auch_immer), ist erstmal egal - hauptsache derselbe.

Da das Problem nur in eine Richtung aufzutreten scheint (sV-->fronthem), kannst Du entweder die Senderseite im sV-Treiber anfassen und gleich in einem fronthem-genehmen Zeichensatz senden (würde ich nicht machen - die Umstellung auf UTF-8 ist IMHO der richtige Weg):

# Java
io.socket.send(JSON.stringify(data));  // gesendet wird UTF-8; hier ggf. in den richtigen Zeichensatz encoden

... oder Du passt die Empfängerseite an, indem Du den empfangenen String vor der Verarbeitung in ein genehmes Format bringst (wie hier zu ISO8859):

# Perl
$up = decode_json($msg);

Beispiel: Aus '$up = decode_json($msg);' wird dann vielleicht sowas wie 'use Encode; $up = decode_json(Encode::encode("ISO-8859-1", $str));'. Ich habe aber in meinem Leben genau NULL Codezeilen in Perl geschrieben, daher kann die konkrete Umsetzung durchaus ganz anders aussehen.

Weiterhin scheint auch fronthem noch am Zeichensatz rumzufrickeln (siehe Antwort hier). Das sollte auf der einen Seite vermutlich irrelevant sein, solange Sender und Empfänger während der Kommunikation die gleiche Sprache sprechen und die Information richtig ankommt. Andererseits kann es aber auch 'die Wurzel des Übels' sein, da irgendwo in FHEM/fronthem während der Verarbeitung nochmal um-/nachcodiert wird.

Vielleicht hilft Dir das alles wenig weiter. Meine eigene Herangehensweise an Deiner Stelle wäre jetzt einfach mal ein Abend try-and-error, mit ganz viel Unterstützung von Tante Google. Viel Erfolg!

/tom