Ankündigung

Einklappen
Keine Ankündigung bisher.

Umlaute ans Backend übertragen (shNG, fhem)

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    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?
    Code:
    error malformed UTF-8 character in JSON string
    Was habe ich gemacht:

    Änderung im smartVISU-FHEM-Treiber
    Code:
    io.socket.send(unescape(encodeURIComponent(JSON.st ringify(data))));
    auf
    Code:
    io.socket.send(JSON.stringify(data));
    Es kommen kein Texte mit Umlauten mehr an. Im FHEM-LOG steht dann folgender Fehler
    Code:
    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.

    Kommentar


      #17
      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

      Kommentar


        #18
        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
        Code:
        #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

        Kommentar


          #19
          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

          Kommentar


            #20
            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
            Code:
            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.
            Code:
            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:
            Code:
            $msg = decode_json($msg);
            mit der geänderten Zeile im FHEM-Treiber
            Code:
            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.
            Code:
            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:
            Code:
            $up = decode_json($msg);

            Kommentar


              #21
              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:

              Zitat von wvhn Beitrag anzeigen
              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

              Kommentar


                #22
                Zitat von Tom Bombadil Beitrag anzeigen
                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.

                Kommentar


                  #23
                  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):
                  Code:
                  # 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):
                  Code:
                  # 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
                  Zuletzt geändert von Tom Bombadil; 29.03.2022, 12:13.

                  Kommentar

                  Lädt...
                  X