Hallo zusammen,
ich versende und empfange Strings per MQTT welche JSON codiert sind.
Leider geht das bei Sonderzeichen total schief.
Hier mal ein einfacher Beispielcode:
my $sendData = {
text => "Dös öst ön Töxt möt Öhhhhs!"
};
my $json = SNIPS::encodeJSON($sendData);
Log3($hash->{NAME}, 5, $json);
Im Log findet sich dann:
Zitat
{"text":"Dös öst ön Töxt möt Ãhhhhs!"}
Wäre soweit ja noch nicht schlimm, wenn es nur ein Anzeigeproblem in Fhem wäre.
Aber beim Gegenüber (MQTT und dort lauschende Software) kommt es eben auch so an.
Andersherum sehe ich, dass JSON Data die vom Gegenüber reinkommt erstmal normal aussieht (Texte im JSON String beinhalten ganz normal lesbare Sonderzeichen).
Sobald ich dann decode_json drüberjage, sind die Sonderzeichen wieder hinüber.
Muss man hier in Fhem zwecks Codierung der Strings was beachten, oder woran kann das liegen?
Danke schon einmal im Voraus. :)
FHEM intern sollte alles mit UTF-8 codiert sein.
- Falls Du den gezeigten Programmcode mit FHEMWEB erstellt hast, dann sollte das UTF-8 sein.
- Log: ist vermutlich UTF-8 mit einem Programm angezeigt, was von ISO-8859-1 (aka latin1) ausgeht.
- Wie man der anderen MQTT-Seite beibringt, dass es UTF-8 ist, muss da evaluiert werden.
Warum verwendest Du ein externes Modul, anstatt die FHEM-internen Möglichkeiten zu nutzen?
sub test {
my $sendData = { text => "Dös öst ön Töxt möt Öhhhhs!" };
my $json = toJSON($sendData);
Debug $json;
}
liefert bei mir im Log:
2018.07.19 23:49:09 1: DEBUG>{"text":"Dös öst ön Töxt möt Öhhhhs!"}
Zitat von: betateilchen am 19 Juli 2018, 23:50:33
Warum verwendest Du ein externes Modul, anstatt die FHEM-internen Möglichkeiten zu nutzen?
Eine sehr gute Frage. :)
Vielleicht weil es mein erstes Modul ist, an dem ich für FHEM arbeite und generell noch viel zu entdecken habe? ;)
Vielen Dank für den Hinweis, werde das später daheim testen, dürfte aber das Problem wohl beseitigen.
Mal sehen ob ich das Problem in die andere Richtung (decode_json) mit einem passenden encode des Strings bevor dem Aufruf in den Griff bekomme. Die Richtung ist Fhem-intern ja nicht möglich, oder?
edit: Sehe gerade, das Modul expandJson macht das so: decode_json(encode_utf8($dvalue)).
Werde ich so mal testen.
Zitat von: rudolfkoenig am 19 Juli 2018, 23:13:38
FHEM intern sollte alles mit UTF-8 codiert sein.
- Falls Du den gezeigten Programmcode mit FHEMWEB erstellt hast, dann sollte das UTF-8 sein.
- Log: ist vermutlich UTF-8 mit einem Programm angezeigt, was von ISO-8859-1 (aka latin1) ausgeht.
- Wie man der anderen MQTT-Seite beibringt, dass es UTF-8 ist, muss da evaluiert werden.
Das Zitat "Log" ist aus dem FHEM Logfile, erzeugt durch den Log3 Befehl im Sample Code.
Angezeigt ganz normal im Browser.
Logge ich zusätzlich noch Folgendes, sehe ich dort die Sonderzeichen ganz normal.
Am Browser oder dem Encoding des Editors mit dem der Code erstellt wurde dürfte es also eigentlich auch nicht liegen:
Log3($hash->{NAME}, 5, "Dös öst ön Töxt möt Öhhhhs!");
(Habe die Code Datei aber auch nochmal mit FhemWeb editiert um zu sehen ob die Zeichen da passen.)
Somit scheine ich ja schon innerhalb von Fhem/encode_json Probleme mit dem Encoding zu haben, und nicht erst auf der anderen MQTT Seite.
Auch die Mosquitto Konsole zeigt die Sonderzeichen übrigens auf diese falsche Weise an, nicht erst die lauschende Gegenstelle.
Da somit alle Beteiligten den String falsch anzeigen (Fhem, Mosquitto, anderer MQTT Teilnehmer), fürchte ich schon,
dass er auch wirklich falsch ist und beim encode_json was schief geht.
Warum
SNIPS::encodeJSON
Ist in meinen Augen etwas anderes wie
JSON::encode_json
Deweiteren empfiehlt es sich gerade bei dem JSON Modul das ganze in einem eval{} auf zu rufen.
Stimmt, das war doof das oben so reinzukopieren ohne die Funktion aus dem Modul.
Die macht bisher testweise aber noch nichts anderes als:
sub encodeJSON($) {
my ($hashRef) = @_;
# JSON Encode und Fehlerüberprüfung
my $json = eval { encode_json($hashRef) };
if ($@) {
Log3($hash->{NAME}, 5, "Encoding Error");
return undef;
}
return $json
}
Warum um alles in der Welt baut man einen Wrapper um eine vorhandene Funktion?
Weil
Zitat von: Thyraz am 20 Juli 2018, 09:40:14
Die macht bisher testweise aber noch nichts anderes als:
das nicht der finale Zustand ist und nicht den Sinn hat ein simpler Wrapper zu bleiben.
Aber danke der Nachfrage. ;)
Kurze Rückmeldung:
Die Kombination aus toJSON(...) und decode_json(encode_utf8(...)) funktioniert einwandfrei. :)
Danke an alle Beteiligten.