Hallo Rudi,
ist es denkbar, dass FHEMWEB mit UTF-8 Schwierigkeiten hat, sobald man HTTPS einschaltet und darüber zugreift?
https://forum.fhem.de/index.php/topic,59646.msg560020.html#msg560020
Ich kodiere im Modul IMHO eigentlich alles korrekt mit UTF-8, über Plain HTTP ist die Darstellung auch richtig. Wo könnte man hier ansetzen?
Gruß
Julian
Zitatist es denkbar, dass FHEMWEB mit UTF-8 Schwierigkeiten hat, sobald man HTTPS einschaltet und darüber zugreift?
Denkbar ist vieles, und "sag niemals nie", ich wuesste aber nicht wie. HTTPS ist fuer FHEMWEB transparent, decrypt/decompress wird ueber IO::Socket::SSL abgewickelt, und das sollte keine Inhalte aendern. Ich habe gerade auf einem fhem.cfg.demo+HTTPS "attr Office alias Öffice" mit dem erwarteten Resultat gesetzt. Dein Link klingt zwar eher nach HttpUtils Problem, allerdings verwendet das auch IO::Socket::SSL.
ZitatIch kodiere im Modul IMHO eigentlich alles korrekt mit UTF-8
Das gibt mir zu denken: wozu braucht man das?
ZitatWo könnte man hier ansetzen?
Ich wuerde mit "attr global verbose 5" anfangen, und wenn das nicht hilft, die betroffenen Module temporaer mit zusaetzlichen Log versehen. Wenn man es selbst nachstellen kann, minimiert den Aufwand.
Zitat von: rudolfkoenig am 13 Januar 2017, 11:55:06
Denkbar ist vieles, und "sag niemals nie", ich wuesste aber nicht wie. HTTPS ist fuer FHEMWEB transparent, decrypt/decompress wird ueber IO::Socket::SSL abgewickelt, und das sollte keine Inhalte aendern.
Hätte ich auch angenommen. Bliebe wohl noch ein kaputter Browser, was aber auch eher unwahrscheinlich scheint.
Zitat von: rudolfkoenig am 13 Januar 2017, 11:55:06
Das gibt mir zu denken: wozu braucht man das?
z.B. für das (leidige) Thema zur Darstellung von Einheiten, wo sich ja derzeit jedes Modul selbst drum kümmern muss. Die Webseiten kodieren eben teils unterschiedlich und das muss man für FHEM natürlich im Modul gerade rücken.
Zitat von: rudolfkoenig am 13 Januar 2017, 11:55:06
Ich wuerde mit "attr global verbose 5" anfangen, und wenn das nicht hilft, die betroffenen Module temporaer mit zusaetzlichen Log versehen. Wenn man es selbst nachstellen kann, minimiert den Aufwand.
Meine Module bieten diese Debugging Funktion immer von Haus aus. Man sieht dort aber nichts auffälliges was die Verarbeitung innerhalb des Moduls angeht.
Zitat von: rudolfkoenig am 13 Januar 2017, 11:55:06
Ich habe gerade auf einem fhem.cfg.demo+HTTPS "attr Office alias Öffice" mit dem erwarteten Resultat gesetzt.
Versuch mal den String so einzufügen, wie es die Module tun, wenn es um echte Sonderzeichen geht:
{$attr{"utf8_test"}{alias} = '20' . chr(0x202F) . chr(0x00B0) . 'C'}
Zitat{$attr{"utf8_test"}{alias} = '20' . chr(0x202F) . chr(0x00B0) . 'C'}
Das ist sowohl ueber HTTP wie ueber HTTPS kaputt.
"attr utf8_test alias 20°C" funktioniert ueber beide.
Bei mir ist das über HTTP nicht kaputt. (Mac; Browser: Safari, Chrome, Firefox).
Ich bin dann etwas ratlos...
Aber nur um das klarzustellen: "20 °C" direkt zu schreiben ist keine Alternative, weil das Leerzeichen dabei kein normales Leerzeichen sein darf/soll, sondern ein geschütztes Leerzeichen (https://de.wikipedia.org/wiki/Gesch%C3%BCtztes_Leerzeichen).
In diesem Fall sogar ein schmales, geschütztes Leerzeichen, da es sich um eine Gradient Angabe handelt.
Merkwuerdigerweise schaut es nach einer Wiederholung bei mir auch richtig aus (Firefox,Chrome,Safari, jeweils HTTP + HTTPS), wuesste gerne, woran das wiederum liegt.
Zitatein geschütztes Leerzeichen (https://de.wikipedia.org/wiki/Gesch%C3%BCtztes_Leerzeichen).
Das kann man zwar alles machen, ist aber mAn "asking for trouble" (gibts es dafuer einen deutschen Ausdruck?)
Ich habe einen kleinen Test-Dummy definiert, der auch noch eine komische Ansicht offenbart, sobald man einen der 3 Readings mit UTF-8 befüllt. Seltsamerweise kommt es nämlich dann zu einer fehlerhaften Darstellung des Readings, welches man NICHT mit UTF-8 befüllt hat (hier "normal_space" genannt).
define utf8 dummy
setreading utf8 normal_space 20 °C
setreading utf8 protected_narrow-space -
setreading utf8 protected_space -
{$defs{"utf8"}{READINGS}{"protected_narrow-space"}{VAL} = '20' . chr(0x202F) . chr(0x00B0) . 'C'}
{$defs{"utf8"}{READINGS}{"protected_space"}{VAL} = '20' . chr(0x00A0) . chr(0x00B0) . 'C'}
Zitat von: rudolfkoenig am 13 Januar 2017, 16:51:15
Das kann man zwar alles machen, ist aber mAn "asking for trouble" (gibts es dafuer einen deutschen Ausdruck?)
Um das zu beantworten müsste ich nach einem deutschen Äquivalent zu "Because we can" suchen ;)
Für mich (und André) als Unit.pm Befürworter hat es den Grund in UI's einfach eine sehr exakte Darstellung bekommen zu können.
Es gibt auch andere User hier im Forum, die eine exakte Darstellung anstreben und schätzen. Ich bin froh, dass du anerkennt, dass das eine komplexe Angelegenheit ist. Das ist der Grund weshalb André und ich das gerne in Unit.pm generell abnehmen wollen würden, damit sich der User nur entscheiden muss: "Will ich diese Anzeige oder will ich sie nicht?".
Back to topic / TL;DRBeim Wunderground Modul kommt der anfangs genannte Text von den Servern von Wunderground. Ich korrigiere zwar dort manuell noch sowas wie "20C" in "20 °C" (mit dem narrow-space), aber die Umlaute kommen so rein und werden ja ebenfalls falsch dargestellt. Vielleicht hilft ja aber mein Beispiel-Dummy oben, um das besser zu deuten.
Zitatchr(0x202F)
Das ist aber kein UTF-8, sondern Unicode-16.
Wenn ich dein Beispiel direkt ins fhem.cfg packe, dann meldet Perl "PERL WARNING: Wide character in print at fhem.pl line 869.
" beim Start.