Kodierungsproblem iso-8859-1/utf-8 (Modulliste)

Begonnen von RichardCZ, 19 März 2020, 15:57:21

Vorheriges Thema - Nächstes Thema

justme1968

das regex literale auch mit zu den strings im quelltext gehören ist klar. das sind aber nicht die einzigen quellen für regex. und auch hier funktioniert das nur wenn der string auf den die regex angewendet ist mit dem korrekten encoding markiert ist. nicht für byte strings. es muss beides zusammen passen.

ich fürchte das einige der seiteneffekte im endanwender code zuschlagen. also z.b. regex in notify & co. die die endanwender selber schreiben. wenn sich hier die semantik ändert fällt das im schlimmsten fall erst nach monaten auf. noch schlimmer wenn das sicherheitsrelevant ist. ja. das ist ein worst case szenario. aber es ist zumindest denkbar.


das problem mit der perl version ist nicht die fhem seite, sondern die platform seite bei der eventuell keine neueres perl installierbar ist. z.b. die leider noch recht oft verwendete fritzbox.


einen eigenen brach für solche dinge aufzumachen wäre der richtige weg. die frage ist: wie bekommt man die anwender bei zeiten dazu auch diesen branch zumindest mal zu testen. das ganz nützt nichts wenn es nur eine hand voll entwickler mal verwendet hat.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

ZitatBei mir habe ich z.B. alle Prototypes - bis auf einen - aus fhem.pl rausgeschmissen und FHEM läuft immer noch
Das sagt sehr wenig: ich teste meine Aenderungen mit zwei perl Versionen (alt, und neu), und darf trotzdem nach jede nicht irrelevante Aenderung etliche Supportprobleme bearbeiten. Dass ein Einzelner FHEM durchtesten kann ist illusorisch, sowohl was die verwendete Hardware, wie auch die von Benutzern angelegte Codeschnipsel betrifft. Ich bin zwar ZWave Modul-Maintainer, habe aber vmtl 1-2% der prinzipiell unterstuetzten Geraete zur Verfuegung, und nicht mal die kann mit allen Randbedingungen testen.

Zitatdie herde ein wenig antreibt.
Ich bin dagegen: FHEM wird manchmal verwendet, um Probleme zu loesen, und nicht aus Selbstzweck.
Perl upgrade bedeutet in etlichen Faellen OS oder Hardware upgrade, die wiederum nicht die alte Schnittstelle unterstuetzt, oder nur kompliziert, aber der Anwender ist kein IT-Profi.
D.h. um potentielle Probleme zu loesen erzeugen wir Konkrete.

justme1968

noch etwas: die aktuell von fhem intern verwendete repräsentation sind byte strings mit utf-8 encoding byte order. aber eben nicht als utf-8 encoded auf perl ebene markiert. deshalb würden die utf-8 encodierten regex aus dem quelltext mit einem umlaut z.b. nicht matchen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

#18
Sorry, aber das geht in de falsche Richtung!

Können wir uns darauf beschränken Probleme zu beseitigen die real existieren?

Ich sehe genau NULL Notwendigkeit für ein use 5.28 und genauso wenig für ein erzwungenes UTF8 (obwohl ich das verwende). UTF8 bezieht sich auf die Kodierung des Source Text. Wir haben hier schon genug UTF8 Arien gehabt. Die Empfehlung sollte sein 'use UTF8' zu verwenden.

Ansonsten ist jeder maintainer für seine Module verantwortlich und zwar nur der. Gibt es konkrete Probleme dann werden die an den entsprechenden Maintainer gemeldet und der ist verantwortlich die zu beseitigen.


Zitatich fürchte das einige der seiteneffekte im endanwender code zuschlagen. also z.b. regex in notify & co. die die endanwender selber schreiben. wenn sich hier die semantik ändert fällt das im schlimmsten fall erst nach monaten auf. noch schlimmer wenn das sicherheitsrelevant ist. ja. das ist ein worst case szenario. aber es ist zumindest denkbar.
Genau! Zusätzlich zeigt die Erfahrung dass auch Seiteneffekte innerhalb von Modulen erst nach Monaten auffallen.

Edit: volle Zustimmung zu Rudis Beitrag!

rudolfkoenig

Zitateinen eigenen brach für solche dinge aufzumachen wäre der richtige weg. die frage ist: wie bekommt man die anwender bei zeiten dazu auch diesen branch zumindest mal zu testen. das ganz nützt nichts wenn es nur eine hand voll entwickler mal verwendet hat.
Vor (gefuehlt) 5 Jahren haben wir dieses Experiment gewagt, mit dem Ergebnis, dass beim Release (wo "dev" zu "stable" wurde) die grosse Ueberraschung gab, weil kaum Benutzer die Testversion angefasst haben. Und die Entwickler wussten nach einem halben Jahr auch nicht mehr, welche der vielen Aenderungen fuer die gemeldeten Probleme verantwortlich sein koennten.
Dagegen wird trunk von vielen Benutzer regelmaessig per FHEM update erneuert (warum auch immer), und Fehler werden relativ zeitnah gemeldet, was das Leben des Entwicklers erleichtert.

herrmannj

#20
Zitat von: justme1968 am 20 März 2020, 11:00:25
noch etwas: die aktuell von fhem intern verwendete repräsentation sind byte strings mit utf-8 encoding byte order. aber eben nicht als utf-8 encoded auf perl ebene markiert. deshalb würden die utf-8 encodierten regex aus dem quelltext mit einem umlaut z.b. nicht matchen.
Ne das stimmt so nicht.

Perl verarbeitet seit rund 10 Jahren intern alles als unicode, Jeder Char in einem String darf > 0xFF sein. Das UTF8 Flag zeigt nicht an in welcher Kodierung der String vorliegt sondern nur ob perl Zeichen > 0xFF in der Kette erkannt hat.

Kodierungsprobleme tauchen daher in der Regel bei IO Operationen oder der Verarbeitung (Vergleichen, Regex) auf. Zum Beispiel wenn versucht wird ein Zeichen via syswrite zu senden welches > 0xFF ist. Bytestream bezieht sich auf die Konvertierung von Unicode Zeichenketten (> 0xFF) mittels standardisierter Regeln (quasi escapen) auf Zeichenfolgen bestehend 0x00..0xFF.

UTF8 regelt auch welcher Codepoint welchen Zeichen entspricht und innerhalb des Source Code (use UTF8) die _für den_ Source Code verwendete Kodierung. Perl versteht wie es die Zeichenfolge die von der Disk kommt interpretieren muss um ein "ä" in der Datei zu erkennen.

Kodierungen wie 'ä' beziehen sich auf die _Ausgabe_ (hier HTML Kodierung also eine Ausgabe an einen Browser). Das ist ein völlig anderes Thema.

Innerhalb von FHEM tauchen bytestream / Unicode Konvertierungen an vielen Stellen auf. Zum Beispiel wenn eine JSON Quelle gelesen wird (UTF8 Bytestream), dann dekodiert und vom Modul verabeitet wird (Unicode) und anschließend das Ergebnis per Longpoll/Websocket an den Browser geschickt wird (UTF8 Bytestream).




RichardCZ

Ok. Ich hab's versucht - sogar meine Kapazität angeboten.

Ich verstehe, dass man den Legacy-Tsunami fürchtet, aber man möge bitte auch mich verstehen, dass ich mich im Jahr 2020, bei einer neuen Installation nicht von irgendwelchen 15 Jahre alten Fesseln fesseln lassen möchte.

Hab' in der Vergangenheit immer nur so halb begriffen - und es bedauert - warum es zu Forks a la OpenELEC/LibreElec, StarOffice/OpenOffice/LibreOffice, mplayer/mplayer2/mpv kam. Aber jetzt verstehe ich das ein wenig mehr.

¯\_(ツ)_/¯
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

justme1968

@herrmannj:

eben weil fhem davon ausgeht das die internen strings zwar in utf-8 byteorder sind aber tatsächlich auf perl ebene nicht mit utf-8 encoding markiert sind gehen einige dinge schief. dazu gehört die automatische konvertierung die perl eigentlich kann. low level routinen wie syswrite wissen übrigen nichts von irgendeinem encoding.

für syswrite gibt es keine zweichen > 0xff. bytes sind immer 8 bit. sockets arbeiten nur mit 8 bit. encodings kommen weiter oben im schichten modell. gleiches gilt fürs lesen und schreiben von platte. es gibt keine 100% zuverlässige methode das encoding automatisch zu erkennen. an manchen stellen wird ein default encoding angenommen. ob das zum tatsächlichen encoding passt ist eine andere sache. deshalb wäre teil der umstellung auf utf-8 das an jeder stelle and er etwas rein oder raus geht explizit das encoding gesetzt wird. alles andere funktioniert nicht. und das funktioniert auch nur wenn man sich auf eine minimale perl version einigen würde.

die &... notation ist ein workaround um sich nicht auf utf-8 in der ganzen kette verlassen zu müssen. wenn überall das encoding korrekt angeben ist bräuchte man es es für umlaute & co nicht. inzwischen kommt jeder browser mit echten utf-8 daten zurecht.

die 'echten' konvertierungen nach utf8 durch json oder ähnliches sind eines der probleme die es aktuell gibt. weil damit die strings auf perl ebene als utf-8 markiert werden und perl potentiell automatisch konvertieren kann bzw. regex anders arbeiten könnten. das json das rein kommt muss ja nicht unbedingt uff-8 sein. manche devices senden auch latin-1.

in den routinen die die daten für longpoll/websocket senden greift aus diesen gründen auch nicht die perl interne automatische konvertierung sondern es wird von hand gemacht. erinnerst du dich noch an die fehler die es damals manchmal gab? die hat ihre ursache genau da.

einen echten utf-8 umlaut in einer regex in einer fhem quelltext datei funktioniert aktuell nicht. gibt irgendwo einen thread dazu mit meinen versuchen. die kombination aus bytestrings und perl version hat nie zuverlässig funktioniert. deshalb werden an diversen stellen tatsächlich chr byte sequenzen verwendet.


utf-8 kann problemlos funktionen wenn überall ausschliesslich korrekt markierte und encodete strings mit den dafür vorgesehen perl mechanismen verarbeitet werden. sobald an einer stelle von hand dazwischen gefunkt wird breitet sich das wie lawine aus und überall muss von hand korrigiert werden. das ist leider der aktuelle zustand. das zu ändern bedeutet es an jeder stelle der ganzen kette zu ändern. was leider an den altern perl versionen scheitert.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

ZitatOk. Ich hab's versucht - sogar meine Kapazität angeboten.
Wie bei den alten Menschen: sie haben ihre Verpflichtungen, Gewohnheiten und Erfahrungen, ein stuermischer Jugendlicher kann nicht alles einfach aendern.
Es sei denn, er geht es Vorsichtig an :)

RichardCZ

Zitat von: rudolfkoenig am 20 März 2020, 12:10:14
Wie bei den alten Menschen: sie haben ihre Verpflichtungen, Gewohnheiten und Erfahrungen, ein stuermischer Jugendlicher kann nicht alles einfach aendern.
Es sei denn, er geht es Vorsichtig an :)

Da ich dieses Jahr 50 werde, fasse ich das mal als Kompliment auf.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

herrmannj

ZitatIch verstehe,

Nein ich glaube nicht das Du verstehst.

Wenn Du an diesen Baustellen arbeiten möchtest: sehr gern. Nur dann ist es eben nicht mit einem grep über Dein Repo und lautem tata getan. Das hat was mit Fleißarbeit zu tun, Du musst Dir die Module anschauen, verstehen und bitte dem maintainer des moduls die getesteten Bugfixes liefern.

https://perldoc.perl.org/Encode.html

Einfaches Beispiel zu UTF8, 'Ñ'

Ein length($bytestream_codiert) liefert eine 4. Ein length($char) liefert eine 1. Ein foreach (split //, $bytestream_codiert) {$i++} gibt in einer Verabeitung 4 Schleifendurchläufe.

Ein erzwungenes 'use UTF8;' ändert dies nicht, hat aber das Potential Nebeneffekte (das sind dann BUGS) in jetzt laufenden Modulen zu erzeugen. Daher ist es unbedingt erforderlich den Impact von Änderungen zu verstehen und übersehen zu können.


herrmannj

@Andre:
Zitateben weil fhem davon ausgeht das die internen strings zwar in utf-8 byteorder sind
Das sagst Du in Deinem jugendlichen Leichtsinn ;) - stimmt aber so nicht. Nimm mein JSON Beispiel. Zumindest wenn der Autor JSON::XS (und vermutlich auch Rudi's JSON) nimmt passiert die Konvertierung automatisch und da fallen Unicode raus. Aber schau mal im Forum nach den 'illegal widechar' Meldungen (an den genauen Fehlertext erinnere ich mich nicht).

Ich bin auch nicht gegen Änderungen sondern ausdrücklich für Verbesserungen. Aber doch bitte auf die Probleme konzentriert. Prototypen?, use UTF8? .. das macht was genau besser? das macht nur eins: Support Anfragen im Forum weil irgendwas nicht mehr läuft. Vielleicht fehlt mir die Quarantäne Langeweile um den Spass für mich zu erkennen.

justme1968

genau die meldung meine ich. die kommt weil die tatsächliche interne repräsentation nicht zur von perl erwartet passt und nirgendwo explizit das encoding gesetz wird. deshalb gehen die automatischen mechanismen nicht. deshalb gibt es in FW_addToWritebuffer die byte weise zu fuss behandlung.

wenn man konsequent überall das encoding richtig setzen könnte, würde perl alles automatisch machen. man könnte sogar das encoding für die fhemweb ausgabe konfigurierbar machen und perl kümmert sich um den rest. ist zwar kein besonders gutes beispiel, aber damit wäre auch das problem behoben das es bestimmte kombination aus fhem, perl version und browser version gibt die scheinbar das default encoding auswürfelt. ist eine weile her war aber ein ziemlicher krampf. mehrfach laden und/oder fhem neu start hat die darstellung der sonderzeichen im browser geändert.

ist aber eigentlich alles am thema vorbei. das komplett und richtig zu machen wäre schön, es gibt aber wichtigere baustellen mit weniger nebeneffekten und mehr zufriedenen nutzern. hier behalten wir ja im besten fall nur die zufriedenen und es werden nicht mehr. im normal und schlimmsten fall werden es weniger weil es alle möglichen nebeneffekte gibt :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

viegener

Zitat von: herrmannj am 20 März 2020, 12:31:38
@Andre:Das sagst Du in Deinem jugendlichen Leichtsinn ;) - stimmt aber so nicht. Nimm mein JSON Beispiel. Zumindest wenn der Autor JSON::XS (und vermutlich auch Rudi's JSON) nimmt passiert die Konvertierung automatisch und da fallen Unicode raus. Aber schau mal im Forum nach den 'illegal widechar' Meldungen (an den genauen Fehlertext erinnere ich mich nicht).

Ich bin auch nicht gegen Änderungen sondern ausdrücklich für Verbesserungen. Aber doch bitte auf die Probleme konzentriert. Prototypen?, use UTF8? .. das macht was genau besser? das macht nur eins: Support Anfragen im Forum weil irgendwas nicht mehr läuft. Vielleicht fehlt mir die Quarantäne Langeweile um den Spass für mich zu erkennen.

Genau an der Stelle habe ich monatelang mit Telegram gehadert bis ich festgestellt habe, dass das je nach Kombination von perl-Version mit JSON-Modul unterschiedlich ausgeht, so dass ich am Ende einen speziellen UTF8-Schalter für zusätzliche de/encodes einbauen musste.

Zur grundsätzlichen Frage - ja ich fände es sinnvoll hier mehr zu vereinheitlichen und Richtung mehr UTF-8 zu gehen.

Wie wäre es mit einem Vorschlag:
- Wie wäre es erstmal mit einem commithandler, der es erforderlich macht ISO8859-codierte Inhalte speziell zu maskieren? Mann könnte auch erstmal mit einer Warnung anfangen.
- Solche Änderungen die einige Module betreffen sind doch schon früher auf diesem Weg angegangen worden.

Von da aus geht es Schritt für Schritt weiter ?
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

RichardCZ

#29
Ich habe in meinem Repo alle Umlaut-Entities ersetzt. bei der Gelegenheit bin ich auf ein paar Bugs gestossen:

52_I2C_PCF8574.pm

Da hat der Maintainer &oml; &aml; ¨ statt ä ... verwendet

weitere mit dem gleichen Fehler:

73_GardenaSmartBridge.pm
75_msgConfig.pm
86_Robonect.pm
89_VCONTROL.pm
96_SIP.pm

Gern geschehen.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.