Hallo,
in JSON sind nichtdruckbare Steuerzeichen nicht zulässig. Sofern solche Sonderzeichen vorkommen, führt das bei Longpoll zu einer Fehlermeldung beim Client (in Firefox z.B. parsererror, SyntaxError: JSON.parse: bad control character in string literal at line 4018 column 28 of the JSON data). Steuerzeichen lassen sich nicht immer vermeiden. So ist beispielsweise das Attribut requestSeparator bei ECMD ggf. ein Steuerzeichen (\0).
M.E. müsste die Maskierung in FHEMWEB vervollständigt werden. Gehe ich recht in der Annahme, dass das ab Zeile 2516 geschehen müsste? Hier der aktuelle noch nicht geänderte Code:
my %jsTab = ( 92=>'\\\\', 34=>'\\"', 9=>'\\t', 13=>'\\r', 10=>'\\n' );
sub
FW_longpollInfo($@)
{
my $fmt = shift;
if($fmt && $fmt eq "JSON") {
my @a;
map { my $x=$_; $x=~s/([\\"\t\r\n])/$jsTab{ord($1)}/ge; push @a,$x; } @_;
return '["'.join('","', @a).'"]';
} else {
return join('<<', @_);
}
}
Viele Grüße
Boris
Da wirst Du wohl Recht haben, es dauert aber noch zwei Wochen, bis ich das anpassen kann. Kommt auf die Todo Liste
Es ist auch noch in JsonList und JsonList2 (letzteres wird von TabletUI verwendet).
Anbei eine rustikale Lösung als Patches.
Habe die Patches unveraendert angewandt und eingecheckt. Ich meine deine Aenderungen sind OK und die Module kann man weiterhin laden, aber einen Test mit kaputten Daten habe ich nicht durchgefuehrt.
Danke!
Seit dieser Änderung werden bei mir gewisse Zeichen nicht mehr korrekt kodiert zurück gegeben, wenn sie per Longpoll aktualisiert werden. Hier ein Beispiel mit dem Zeichen °. Das Bild enthält teilweise Werte, die per Longpoll aktualisiert wurden. Alle Zeilen, in denen das° korrekt dargestellt wird, wurde noch nicht per Longpoll aktualisiert.
Hallo,
das kann ich bei mir nicht nachstellen. Es sieht für mich wie ein Kodierungsproblem aus (Latin1 vs. UTF-8). Seit der Anpassung werden Zeichen, die in JSON nicht erlaubt sind, als \uxxxx unikodiert gesendet. Was zeigt Dir Dein Browser denn als Kodierung der von FHEM ausgelieferten Seite an? Bei mir ist es UTF-8.
Viele Grüße
Boris
Hm. Warum sollte es die Textkodierung im Browser sein, wenn es nur die per Longpoll ausgelieferten Inhalte betrifft und genau mit der Version mit diesem Patch vorhanden ist und mit der vorherigen Version nicht (nach restore)? Das erschließt sich mir nicht. Die Textkodierung im Firefox, Chrome, Internet Explorer und allen anderen Browsern und auf allen Devices, die ich verwende, ist UTF-8.
Und ja, ich weiß sehr genau, was ich tue. ;)
Hallo Boris
Bei mir hat sich gerade ein User gemeldet dem nun einige Anzeigen in TabletUI Fehlerhaft, also mit falschen Zeichen bei Umlauten angezeigt werden. Wäre das auch eine Möglichkeit auch denn es hier FHEMWEB betrifft?
Grüße
In der FHEM App auf dem iPhone gehen Räume mit Umlauten nicht mehr und werden Fehlerhaft dargestellt
Hallo Rudi,
ich schlage vor, alle 3 Patches zurückzudrehen, und herauszufinden,warum die Maskierung nicht funktioniert (aber bei mir). Dann mit einer anderen Lösung in einer zentralen sub JSONEncode () neu starten.
Viele Grüße
Boris
Zitat von: CoolTux am 04 Oktober 2016, 22:36:30
Hallo Boris
Bei mir hat sich gerade ein User gemeldet dem nun einige Anzeigen in TabletUI Fehlerhaft, also mit falschen Zeichen bei Umlauten angezeigt werden. Wäre das auch eine Möglichkeit auch denn es hier FHEMWEB betrifft?
Grüße
Ja genau dieses Problem habe ich.
Ich habe jetzt
FHEM/01_FHEMWEB.pm
FHEM/98_JsonList.pm
FHEM/98_JsonList2.pm aus meiner Sicherung vom 19.09. genommen seitdem läuft wieder alles richtig.
Werden die .pm`s wieder aktulisiert das bei einem Update wieder alles richtig läuft?
Viele Grüße Thomas
Zitatich schlage vor, alle 3 Patches zurückzudrehen, und herauszufinden
Habs gemacht, steht ab sofort per update zur Verfuegung.
An die mit Problemmeldungen: koennt ihr bitte eine _einfache_ Konfiguration posten (oder diff zu fhem.cfg.demo), mit dem wir das Problem reproduzieren koennen?
@Boris: kannst du bite das Gleiche fuer dein Problemfall machen?
@Rudi
https://forum.fhem.de/index.php/topic,58520.msg498871.html
Da findest du eine tolle Lösung zum testen.
Die Lösung ist nur halb-toll, es kommt dabei die Meldung:
ZitatGlobal symbol "$vjs" requires explicit package name at (eval 15) line 1.
Wenn ich in telnet folgendes Eingebe:
Zitatfhem> encoding latin1
encoding changed to latin1
fhem> trigger web JS:window.alert('Ä\nÖ\t\\Ü')
dann sehe ich in der Tat in einem parallel geoeffneten Browser Fenster das Problem, und das ist mAn so zu erklaeren:
- FHEM speichert intern alles in UTF-8
- bei UTF-8 darf man BYTES, die groesser als 0x7E sind, nicht mit \uXXXX ersetzen (wenn ich https://de.wikipedia.org/wiki/UTF-8 richtig verstehe, und der Autor da kein Mist erzaehlt), nur alles zwischen 0 und 19 plus \ und "
Ich habe das jetzt implementiert und eingecheckt, brauche aber weiterhin den Problemfall von Boris.
irgendwo ist noch was inkonsistent.
define uff8 dummy;
setreading utf8 state Ä ö ü; °;C
wird in der device detail ansicht zunächst als Ä ö ü °C angezeigt. erst nach longpoll update durch nochmaliges setreading eingabe dann als Ä ö ü °C. in der raum übersicht wird es scheinbar immer korrekt angezeigt.
Das ist eine ganz andere Baustelle:
- makeTable in 01_FHEMWEB.pm escaped (wie heisst das auf deutsch eigentlich?) HTML, bis auf das kuerzlich eingefuehrten <html>.*</html>
- die Statusanzeige (FW_devState) macht sowas nicht
- die longpoll Anzeige in fhemweb.js nimmt HTML an (Zeile 638: $(this).html(d[2]);), richtig waere .html() fuer <html>.*</html>, sonst .text().
Umbau ist relativ einfach, FW_devState ist aber problematisch, weil da nochmal ein <div> mit title um den Wert herum gestrickt wird, und weil diverse Widgets (readingsGroup?) HTML fuer diesen Teil zurueckschicken.
Vorschlag: FW_devState bleibt, fhemweb.js Zeile 638 wird umgebaut.
Habs so eingecheckt, bitte testen.
Zitat von: rudolfkoenig am 05 Oktober 2016, 08:56:55
@Boris: kannst du bite das Gleiche fuer dein Problemfall machen?
Mache ich, bin aber vor dem WE nicht an meinem Rechner. Bitte um Geduld.]
leider gibt es immer noch probleme mit der aktuellen lösung: https://forum.fhem.de/index.php/topic,14425.msg499805.html#msg499805 (https://forum.fhem.de/index.php/topic,14425.msg499805.html#msg499805). ich habe kurz geschaut und es liegt daran das anführungzeichen durch \u0022 ersetzt werden. damit ist der string nicht mehr valides html.
auf die schnelle habe ich getestet das es hilft den string in <html></html> einzuschliessen. das hilft aber nur weil dadurch das komplette maskieren abgestellt wird. das geht natürlich schief wenn im string zeichen drin sind die in json nicht erlaubt sind.
die 'korrekte' lösung muss:
- json und html encoding regeln trennen
- auf fhem seite json korrekt encoden
- auf js seite das json korrekt decoder
- was auf fhem seite los geschickt wird muss auf js seite nach encoden und decoden identisch ankommen.
ich hatte noch keine zeit zu schauen an welchem der 4 punkte es genau noch nicht passt.
habe noch etwas weiter geforscht. es sind nicht die \u0022 sondern das neue maskieren von html. wenn ich <html>...</html> für die longpoll updates verwende ist es ok. das habe ich jetzt erst mal so eingecheckt.
mal sehen ob es weitere nebeneffekte gibt.
Hallo,
habe versucht, die Situation von vor einigen Wochen nachzustellen mit der aktuellen Version aus dem Repo.
Das Problem entstand, wenn ein Attribut mit einem Wert vorbelegt wird, der in JSON nicht vorkommen darf. Das wurde nicht korrekt maskiert. Das tritt z.B. bei ECMDDevice auf, wenn \000 als Trenner verwendet wird, Mit der folgenden Minimalkonfiguration kann man das herstellen:
attr global statefile fhem.save
attr global verbose 5
attr global port 7072 global
attr global modpath /pfad/zum/fhem-code/fhem
define ui FHEMWEB 8083 global
define D Dummy
set D Anfangswert
{ $attr{D}{killer}="\000" }
Den resultierenden JSON-Kode lasse ich mir dann mit
http://meinfhemserver:8083/fhem/?cmd=jsonlist2+D
anzeigen. Ich habe aber den Befehl nicht mehr hinbekommen, durch ein HTTP GET die Gesamtkonfiguration direkt als JSON zurückliefern zu lassen. Bei fehlerhaftem JSON-Kode gibt das nämlich auch gleich Gemecker vom Browser.
Viele Grüße
Boris
Hallo,
ich habe mit der obigen Konfiguration aber noch was viel schlimmeres: die Konsole geht nicht mehr.
neubert@sauron:~$ telnet sauron 8083
Trying 127.0.1.1...
Connected to sauron.
Escape character is '^]'.
list
HTTP/1.1 302 Found
Content-Length: 0
Location: /fhem
Connection closed by foreign host.
Nach Eingabe von list drücke ich Enter. Nichts passiert. Ich drücke nochmal Enter. Die HTTP-Meldung erscheint und die Session stirbt. FHEM läuft aber weiter. Im Log steht dazu:
2016.10.09 11:09:14 4: Connection accepted from ui_127.0.0.1_45794
2016.10.09 11:09:17 4: ui_127.0.0.1_45794 list ; BUFLEN:0
2016.10.09 11:09:17 4: ui: redirecting to /fhem
Ich habe einen extra Beitrag aufgemacht, damit er als neues Thema abgespalten werden kann, wenn es ein anderes Problem ist.
Viele Grüße
Boris
Aeh: list ist doch kein HTTP Befehl.
Versuch mal sowas wie (zweimal RETURN am Ende), funktioniert bei mir, und liefert HTML zurueck.
GET /fhem?cmd=list
Ich fuehle mich unwohl mit deinem Attributswert, als C-Programmierer ist mir das 0 Zeichen immer suspekt.
Im JSON steht jedenfalls was Richtiges:
"Attributes": {
"killer": "\u0000",
"userattr": "killer"
}
Zitat von: rudolfkoenig am 09 Oktober 2016, 12:03:57
Aeh: list ist doch kein HTTP Befehl.
:-[ :-[ :-[ Ich schäme mich.
Oh dear! Ich bin so was von urlaubsreif. Das Wochenende macht mich fertig. Ich kann nach 10 Jahren FHEM 7072 nicht mehr von 8083 unterscheiden. Entschuldige, dass ich Dir mit meinem Unfug die Zeit gestohlen habe.
Viele Grüße
Boris
Hallo Rudi,
Zitat von: rudolfkoenig am 09 Oktober 2016, 12:13:17
Ich fuehle mich unwohl mit deinem Attributswert, als C-Programmierer ist mir das 0 Zeichen immer suspekt.
solange wir Binärdaten in Readings und Attributen nicht verbieten, müssen wir überall in FHEM damit rechnen. Es betrifft den ganzen Bereich der nichtdruckbaren Zeichen, insbesondere \n und \r. Insbesondere sehe ich derzeit eine Schwierigkeit darin, wie Sonderzeichen über die verschiedenen Wege nach FHEM hereinkommen sollen (Konfigurationsdatei, Telnet, Webinterface, fhem.save) und wie sie dem Benutzer angezeigt werden (Webinterface, Logdateien). Anfang des Jahres ist das Problem bei meinem ECMD hochgepoppt, da dort weder bei der Eingabe klar ist, ob im Log \r nun Backslash-R oder Carriage Return bedeutet, und wie ich Carriage Return ins Attribut reingeschrieben bekomme. Das Problem ist weniger die konsistente Umsetzung sondern die Vereinbarung, wie wir mit Sonderzeichen grundsätzlich umgehen wollen, was also "konsistent" bedeutet. Das müssen wir ein andermal in einem anderen Thread erörtern - meine FHEM-Entwicklungskapazitäten incl. Diskussionen dazu sind leider derzeit ausgenullt.
Zitat
Im JSON steht jedenfalls was Richtiges:
"Attributes": {
"killer": "\u0000",
"userattr": "killer"
}
Genau. Das ist Ergebnis der Änderungen, die Du gemacht hast. Mein Problem, weswegen ich das Thema eröffnet habe, ist damit wohl erledigt.
Viele Grüße
Boris
kann es sein, das hier noch ein "x" fehlt?
Zeile 2711
sub
FW_longpollInfo($@)
{
my $fmt = shift;
if($fmt && $fmt eq "JSON") {
my @a;
map { my $x = $_; #Forum 57377, ASCII 0-19 \ "
- $x=~ s/([\x00-\x1f\x22\x5c\7f])/sprintf '\u%04x', ord($1)/ge;
+ $x=~ s/([\x00-\x1f\x22\x5c\x7f])/sprintf '\u%04x', ord($1)/ge;
push @a,$x; } @_;
return '["'.join('","', @a).'"]';
} else {
return join('<<', @_);
}
}
Ja, danke, habs geaendert.