FHEM und UNICODE, first aid

[Adimarantis]

Die Icons mit HTTPSRV funktionieren jetzt, danke!
Beim Update hakts aber noch (habe jetzt nur FHEMWEB und update vom svn aktualisiert - fehlt noch was?)

Jetzt hab ich noch was mit FTUI gefunden: in  <div data-type="calview"> fehlen der Text von Einträgen mit Umlauten.
Das liegt aber wohl irgendwo im FTUI Javascript. In CALVIEW schaut es gut aus

Code: [Auswählen]

t_003_summary  RestmüllGanz interessant ist, das ein "set update" auf die CALVIEW device dazu führt, dass die Einträge auftauchen, aber wenn die Seite neu aufgebaut (oder refreshed) wird, die Einträge mit Umlauten verschwinden. Nachdem ja schon geraume Zeit an FTUI3 gebaut wird, wird das wohl keiner mehr fixen....

[rudolfkoenig]

Beim Update hakts aber noch (habe jetzt nur FHEMWEB und update vom svn aktualisiert - fehlt noch was?)

Ja, HttpUtils.pm. HttpUtils_NonblockingGet (und die blocking Variante auch) kennt jetzt den Parameter forcedEncoding, wenn das ein Leerstring ist, wird kein Encoding durchgefuehrt, sonst das im HTTP spezifizierte ueberschrieben.

Keine Ahnung, ob und wenn ja was ich in meinen Modulen ändern muss (oder soll?).

Das sollte aus dem ersten Beitrag dieser Thema ersichtlich sei, und ich habe es bisher auch nur zweimal erklaert.
  https://forum.fhem.de/index.php/topic,126088.msg1209560.html#msg1209560
  https://forum.fhem.de/index.php/topic,126088.msg1208705.html#msg1208705
Ich versuchs nochmal:
  Wenn "attr global encoding unicode" gesetzt (und damit $unicodeEncoding=1) ist, dann gilt:
  Alle FHEM-Internen Strings sind Unicode. Darauf muss man beim Einlesen und Rausschreiben der Daten achten, und notfalls passend konvertieren.  Zum Konvertieren sollte man die Encode::encode bzw. Encode::decode Routinen nehmen.

FHEM-Update funktioniert jetzt bei mir auch nicht mehr:

Das habe ich erst gestern Abend gefixt, per FHEM update ist das seit heute verfuegbar.

Sobald ich das "ü" über den Link AdditionalCss beim F18-Style wieder manuell korrigiere ist alles i.O. bis zum nächsten Neustart (trotz vorherigem Save!)

Kann ich nicht nachstellen, weder mit noch ohne CodeMirror.
Kannst Du bitte pruefen, was in fhem.cfg nach einem Save steht?
Steht attr global encoding auf unicode?

[Beta-User]

und ich habe es bisher auch nur zweimal erklaert.

Ich lese das jetzt das dritte Mal und fühle mich weiter als DAM. Vielleicht hilft eine Anzahl konkreterer Beispiele:

RHASSPY nimmt von folgenden Schnittstellen Daten entgegen:
- Usereingaben per Attribut (kann auch Antwortsätze* enthalten)
- Usereingaben per seperater Konfigurationsfile (mögliche Antwortsätze*), eingelesen per FileRead()
- HTTP-Schnittstelle per HttpUtils_NonblockingGet
- MQTT-Schnittstelle, typischerweise über MQTT2_CLIENT-Dispatch

RHASSPY sendet an folgenden Schnittstellen Daten:
- FHEMWEB&Co über list
- HttpUtils_NonblockingGet
- MQTT (IOWrite)

Die Gegenstelle (EDIT: ein externer Serverdienst namens Rhasspy) erwartet - soweit erkennbar - Daten im UTF-8-Format. Dabei kann es sich handeln um:
- Konfigurationsdaten (typischerweise abgeleitet aus den Attributen und der Konfigurationsfile)
- Sätze für die Sprachausgabe (*gebildet aus den oben genannten "Antwortsätzen", die auch nach Auflösung von Variablen "irgendwelche" Infos enthalten können, die z.B. per ReadingsVal() oder InternalVal() abgefragt wurden)
- "technische Parameter" wie die Bezeichnung des Gerätes, an dem die Sprachausgabe erfolgen soll, eine Sitzungs-Kennung usw..

Stellt sich die Frage, an welchen Stellen dann bei "if($unicodeEncoding)" tatsächlich die Abfrage bzw. Konvertierung zu machen ist...

Übersetzt auf obige Aufzählung käme ich jetzt auf folgendes:

RHASSPY nimmt von folgenden Schnittstellen Daten entgegen:

- Usereingaben per Attribut (kann auch Antwortsätze* enthalten) => Konvertierung erledigt fhem.pl (?), man hat dann "nur" das Problem, dass die Daten dann im "falschen" Format sind (?)
- Usereingaben per seperater Konfigurationsfile (mögliche Antwortsätze*), eingelesen per FileRead() => Konvertierung erforderlich (da File bisher im UTF-8-Format verteilt wurde)
- HTTP-Schnittstelle per HttpUtils_NonblockingGet => erledigt fhem.pl
- MQTT-Schnittstelle, typischerweise über MQTT2_CLIENT-Dispatch = erledigt fhem.pl (was aber nach Auffassung eines Teils der Meinungen hier falsch ist!)

RHASSPY sendet an folgenden Schnittstellen Daten:

- FHEMWEB&Co über list => erledigt fhem.pl, hat aber uU. Probleme, wenn Daten nicht konvertiert wurden (?)
- HttpUtils_NonblockingGet => konvertiert automatisch nach UTF-8 (?)
- MQTT (IOWrite) => braucht Konvertierung

Anders gesagt: Aktion erforderlich beim Lesen von Dateien und vor MQTT2-IOWrite.

Korrekt?

[betateilchen]

Ich lese das jetzt das dritte Mal und fühle mich weiter als DAM.

Das geht nicht nur Dir so, und ich habe das schon mehr als dreimal gelesen.

Ich versuchs nochmal:
  Wenn "attr global encoding unicode" gesetzt (und damit $unicodeEncoding=1) ist, dann gilt:
  Alle FHEM-Internen Strings sind Unicode. Darauf muss man beim Einlesen und Rausschreiben der Daten achten, und notfalls passend konvertieren.

Damit kann ich immer noch nicht viel anfangen, auch nicht, wenn das noch 5 Mal geschrieben wird.

• was bedeutet "notfalls" im Zusammenhang mit "passend konvertieren"? Welcher Notfall muss da vorliegen?
• was bedeutet "innen" und "aussen" im Zusammenhang mit FHEM?
• wenn ich Daten, deren Herkunft und Bedeutung ich ggf. nicht kenne, aus FHEM "rausschreibe" und exakt die gleichen Daten von der gleichen Stelle wieder "einlese", um sie in FHEM zu verwenden: warum muss ich sie zuerst hin- und dann wieder zurückkonvertieren, damit am Ende der Ursprungszustand wieder existiert?

[rudolfkoenig]

@Beta-User: wenn dein Modul nur ueber FHEM-Framework Funktionen mit der Aussenwelt kommuniziert (keine syswrite/sysread/etc) dann musst du nichts machen. Die Konvertierung ist Aufgabe denjenigen, die mit der Aussenwelt im direkten Kontakt stehen.

Dem gegenueber steht der Vorschlag, bestimmte Daten (z.Bsp. MQTT-payload) nicht zu konvertieren.
Ich bin gegen diesen Vorschlag, weil damit nicht mehr gesagt werden kann, welche Daten im System als bytestream oder als Unicode vorliegen, und wer genau soll wann konvertieren. Z.Bsp. wenn das JSON vor dem JSON Dekoder mit einer Funktion oder Regexp bearbeitet werden soll.

@betateilchen:
1) "notfalls" heisst, dass dein Modul Daten mit der Aussenwelt austauscht, _UND_ die verwendete Bibliothek keine Konvertierung vornimmt.
2) "innen" ist das, was im FHEM Prozess vorhanden ist, "aussen" ist alles ausserhalb vom FHEM-Prozess (Datei, andere Prozesse, DB, etc)
3) weil man mit "encoding unicode" innen alle Strings als "unicode"(aka Wide-Characters) abgespeichert sind, und solche nicht ohne Weiteres rausschreiben kann, weil sie als Folge von 16-bit (oder 32-bit?) Zahlen gespeichert sind. Diese Daten muss man vorher zum bytestream serialisieren. Z.Bsp. nach iso-8859-1 (aka Latin1), hier wird aus einem Smiley "?" und geht damit verloren. Die Mehrheit verwendet aber UTF-8, damit die Smileys erhalten bleiben

Die aktuelle Voreinstellung in FHEM ist "encoding bytestream", damit ist keine Konvertierung notwendig, und auch keine Unterscheidung von innen/aussen, etc. Viele Perl-Bibliotheken bestehen aber auf Unicode, d.h. je mehr Perl-Bibliotheken in FHEM eingesetzt werden, desto problematischer wird das aktuelle Modell. Und dann gibt es das (mAn unbedeutende) Problem von Regexp-Matching mit Umlaut, und Zugriff auf bestimmte Zeichenpositionen (da Zeichen nicht gleich Byte ist)

[Beta-User]

@Beta-User: wenn dein Modul nur ueber FHEM-Framework Funktionen mit der Aussenwelt kommuniziert (keine syswrite/sysread/etc) dann musst du nichts machen.

Danke für diese klare Aussage. Es zahlt sich also aus, wenn man bevorzugt/wenn möglich die "internen" Funktionen nutzt , und ansonsten den "sowieso-Tipp" von herrmannj beherzigt, möglichst gar keine Konvertierungen zu versuchen (so hatte ich das zumindest verstanden). Das kann man auch DAM wie mir verklickern...

OT-Anmerkung: Es bedingt aber z.B., dass man mit toJSON() serialisierte Strings nachbearbeiten muss, wenn die Gegenstelle eine "strenge Auffassung" davon hat, wie JSON zu interpretieren ist (und z.B. keine Zahlen oder Wahrheitswerte wie true in Quotes akzeptiert)...

Die Konvertierung ist Aufgabe denjenigen, die mit der Aussenwelt im direkten Kontakt stehen.

Dem gegenueber steht der Vorschlag, bestimmte Daten (z.Bsp. MQTT-payload) nicht zu konvertieren.
Ich bin gegen diesen Vorschlag, weil damit nicht mehr gesagt werden kann, welche Daten im System als bytestream oder als Unicode vorliegen, und wer genau soll wann konvertieren. Z.Bsp. wenn das JSON vor dem JSON Dekoder mit einer Funktion oder Regexp bearbeitet werden soll.

Für das konzeptionelle Problem fehlt mir der hinreichende Durchblick über dessen wahres Ausmaß, ich wollte nur neulich nochmal deutlich darauf hingewiesen haben, dass "workarounds" zum "Schutz" von attrTemplate jedenfalls wegen eventuell in meiner Person anfallenden Mehraufwands nicht angezeigt sind. Auch in RHASSPY dürfte das "Problem" überschaubar sein, wenn "unkonvertierte" Daten/Payloads via Dispatch übergeben werden. Ist aber Bauchgefühl...

[Adimarantis]

Update verifiziert. Das geht jetzt.
Gerade versucht ein SVG zu speichern welches Umlaute in den "diagram labels" hatte.
Danach wird das SVG nicht mehr angezeigt:

Code: [Auswählen]

memGzip: Wide character in memGzip at ./FHEM/01_FHEMWEB.pm line 634.
Manuell die Umlaute mit "vi" wieder hergestellt, dann geht es zumindest wieder, aber man bekommt die hübschen karos mit ? drin statt der Umlaute

Mühsam ernährt sich das Eichhörnchen 

[justme1968]

wenn du das karo mit dem fragezeichen siehst hast du einen latin-1 umlaut ins file gebaut.

das encoding das du im file verwendest muss zur encoding angabe in der ersten zeile deines svg files passen.

[Adimarantis]

wenn du das karo mit dem fragezeichen siehst hast du einen latin-1 umlaut ins file gebaut.
das encoding das du im file verwendest muss zur encoding angabe in der ersten zeile deines svg files passen.

War auch nur als Workaround gedacht.
Wobei ich die Fehlermeldung jetzt nicht mehr nachgestellt bekomme, allerdings gebe ich trotzdem Umlaute über den SVG Editor ein (und da stehen sie auch als Umlaute), im Plot jedoch hab die die Fragezeichen - da fehlt also noch irgendeine Umwandlung

[rudolfkoenig]

Gerade versucht ein SVG zu speichern welches Umlaute in den "diagram labels" hatte.

Habs gefixt.
Ist ein Opfer des HTTPSRV Fixes gewesen

Mühsam ernährt sich das Eichhörnchen 

Habs auch so erwartet.

[Adimarantis]

SVG klappt jetzt (und HTTPSRV funktioniert immer noch).

Beim Anpassen meines Moduls habe ich jetzt den umgekehrten Fall:
Selbst wenn FHEM im bytestream Modus ist, verarbeitete ich intern Unicode - was selten ein Problem ist, außer wenn ich Eingaben von FHEM mit Umlauten bekomme.
Da brauche ich zwei mal ein

Code: [Auswählen]

$text=decode_utf8($text) if !($unicodeEncoding);
Etwas nerviger ist, dass für mein Logging zu machen um keine "wide character" Warnungen zu bekommen - da habe ich jetzt mal eine alternative zu Log3 implementiert:

Code: [Auswählen]

sub LogUnicode($$$) {
my ($name,$level,$text) = @_;
$text=encode_utf8($text) if !($unicodeEncoding);
Log3 $name, $level, $text;
}
Könnte man das "encode" nicht generell ins Log3 aufnehmen? Soweit ich das sehe, ist das komplett unschädlich wenn kein Unicode dabei ist, aber hilft jedem der im bytestream Modus "versehentlich" Unicode loggt.

[Benni]

Kann ich nicht nachstellen, weder mit noch ohne CodeMirror.
Kannst Du bitte pruefen, was in fhem.cfg nach einem Save steht?
Steht attr global encoding auf unicode?

Wie gesagt, die Verwendung von CodeMirror sollte auch nach meiner Prüfung dafür unerheblich sein, hatte ich ja auch so geschrieben.
Ja encoding war zu dem Zeitpunkt auf unicode eingestellt.

Eine Prüfung auf das, was in fhem.cfg gespeichert wird, kann ich derzeit leider nicht mehr durchführen, ich habe das encoding-Attribut bei mir wieder entfernt, außerdem habe ich auch auf dem Testsystem configDB im Einsatz, mal sehen ob ich heute Abend in der DB selbst noch schauen kann, was dort in einer älteren Config-Version in die DB geschrieben wurde.

gb#

[rudolfkoenig]

Soweit ich das sehe, ist das komplett unschädlich wenn kein Unicode dabei ist, aber hilft jedem der im bytestream Modus "versehentlich" Unicode loggt

Unschaedlich ist Ansichstsache.
Ein doppeltes "Encode::encode" Aufruf kann Daten kaputtmachen, das habe ich in FHEMWEB schon festgestellt.
Mir ist lieber, dass ein falsches Encoding durch Fehlermeldungen auffaellt, als dass man nie sicher ist, was man hat.

[zap]

@Beta-User: wenn dein Modul nur ueber FHEM-Framework Funktionen mit der Aussenwelt kommuniziert (keine syswrite/sysread/etc) dann musst du nichts machen. Die Konvertierung ist Aufgabe denjenigen, die mit der Aussenwelt im direkten Kontakt stehen.

Gewonnen! Meine Module lesen und schreiben per Socket-Schnittstelle (sysread, syswrite) und verwenden RPC::XML, was sich vermutlich auch nicht um den Zeichensatz schert.

Es bleibt spannend.

[Adimarantis]

Es bleibt spannend.

Für HMCCU & Co kann ich dich beruhigen. Hab schon gut eine Woche umgestellt und kann bisher keine Probleme erkennen. Selbst ein Device mit Umlaut im Namen schaut korrekt aus.