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

[RichardCZ]

Die folgenden Module liegen in iso-8859-1 Kodierung vor:

10_DUOFERNSTICK.pm:          Perl5 module source, ISO-8859 text
10_EIB.pm:                   Perl5 module source, ISO-8859 text, with very long lines
10_EnOcean.pm:               Perl5 module source, ISO-8859 text, with very long lines
10_KNX.pm:                   Perl5 module source, ISO-8859 text, with very long lines
10_KOPP_FC.pm:               Perl5 module source, ISO-8859 text
10_UNIRoll.pm:               Perl5 module source, ISO-8859 text
26_KM273.pm:                 Perl5 module source, ISO-8859 text
30_DUOFERN.pm:               Perl5 module source, ISO-8859 text
36_Vallox.pm:                Perl5 module source, ISO-8859 text, with very long lines
42_SMARTMON.pm:              Perl5 module source, ISO-8859 text
42_SYSMON.pm:                Perl5 module source, ISO-8859 text, with very long lines
51_I2C_BMP180.pm:            Perl5 module source, ISO-8859 text
51_I2C_TSL2561.pm:           Perl5 module source, ISO-8859 text, with very long lines
52_I2C_EEPROM.pm:            Perl5 module source, ISO-8859 text
52_I2C_HDC1008.pm:           Perl5 module source, ISO-8859 text
52_I2C_LM75A.pm:             Perl5 module source, ISO-8859 text
52_I2C_MCP342x.pm:           Perl5 module source, ISO-8859 text
59_OPENWEATHER.pm:           Perl5 module source, ISO-8859 text
64_ESA2000.pm:               Perl5 module source, ISO-8859 text
70_SamsungAV.pm:             Perl5 module source, ISO-8859 text, with very long lines
73_WaterCalculator.pm:       Perl5 module source, ISO-8859 text, with very long lines
74_Unifi.pm:                 Perl5 module source, ISO-8859 text
86_Robonect.pm:              Perl5 module source, ISO-8859 text, with very long lines
89_VCONTROL.pm:              ISO-8859 text, with very long lines
98_dewpoint.pm:              Perl5 module source, ISO-8859 text, with very long lines
98_Siro.pm:                  Perl5 module source, ISO-8859 text, with very long lines

meist kommt dies daher, weil irgendwo im Text - oder in den Kommentaren - deutsche Umlaute sind. Aber auch so Sachen wie "°C".

Ich sehe, dass man an einigen Stellen mit encode/decode arbeitet bzw. arbeiten muss, denn die Ausgabe von FHEM ist natürlich

<meta charset="UTF-8">


und der ganz überwiegende Teil der Module ist natürlich auch UTF-8 kodiert. Ich habe obige Module in meinem Repo bereits konvertiert, kann die also zur Verfügung stellen, damit man das nicht doppelt machen muss. (https://gl.petatech.eu/root/FHEM/-/commit/12bb88053d953afa0d35e673475291c67c47356f)

[RichardCZ]

Der Riesen-Vorteil wenn mann alle Module einheitlich in UTF-8 Kodierung hat und eben auch die Web Ausgabe in UTF-8 ist, dass man a) die Hauptvoraussetzung hat um FHEM z.B. auch in anderen Sprachen anzubieten (sollte das irgendwann passieren), aber vor allem b), dass man sich nicht mehr im HTML code krumm machen muss a la:

Rademacher DuoFern Ger&auml;te

sondern einfach natürlich

Rademacher DuoFern Geräte

schreiben kann. Ich denke, die ganzen HTML-Ampersandkrücken

Code Auswählen Erweitern

90_at.pm:      <li>wenn die aktuelle Zeit gr&ouml;&szlig;er ist als die angegebene Zeit,


sind nur deswegen da, weil man sich früher mit eben solchen Kodierungsproblemen herumgeschlagen hat. Und wer will schon st&auml;ndig &uuml;berm&auml;&szlig;ig maltr&auml;tiert werden.

[rudolfkoenig]

Die Kruecken sind deswegen da, weil ich gerne ASCII habe, damit ich weder mit UTF-8, noch mit latin-1 herumaergern muss.
Ich habe aber nichts gegen UTF-8 als Standard einzuwenden.

[Wzut]

ist jetzt zwar OT , aber ich sehe da oben oft " with very long lines" , daher die Frage : ab wann ist eine Zeile very long ?

[RichardCZ]

Die Kruecken sind deswegen da, weil ich gerne ASCII habe, damit ich weder mit UTF-8, noch mit latin-1 herumaergern muss.
Ich habe aber nichts gegen UTF-8 als Standard einzuwenden.

"Die Krücken waren mal gedacht ... damit ich mich nicht  rumärgern muss."

wolltest Du wohl sagen. Tatsache ist, dass derzeit im Code kein einziges File ASCII ist. Sie sind entweder UTF-8 (mehrheitlich) oder ISO-8859-1 (die paar oben erwähnten). Ich glaube, das nennt sich "Normative Kraft des Faktischen".

Den "Ärger" mit der Kodierung kenne ich - der kommt eben immer genau dann, wenn einige Teile so, andere so kodiert sind. Ich behaupte daher die Krücken waren eher ein Rückzugsgefecht, weil man die Ausgabe der Umlaute sonst nicht auf die Reihe bekommen hat.

Hat man nämlich eine Webseite, die von verschiedenen Codeteilen zusammengesetzt wird und die Strings kommen in verschiedenen Kodierungen an, dann ist das zum Verrücktwerden, weil partout einige Umlaufe falsch dargestellt werden. Und wenn man die fixt, dann werden andere falsch dargestellt. Der Ausweg über HTML Entities bewahrt da tatsächlich oft vor dem Irrenhaus.

Der elegante Ausweg ist oben beschrieben. Sobald das alles einheitlich ist, kann man sogar den Editor die ganzen HTML Entities zurückwandeln lassen (mache ich bei mir gerade) und dann ist die Sache gegessen & wartungsfreundlicher.

Das Einzige worauf man dann noch achten muss ist wenn z.B. ein Modul von extern (Hardware, anderes Subsystem) Daten bekommt und die in irgendeiner anderen Kodierung als UTF-8 sind. Aber dafür gibt es ja Encode - und das ist in CORE, also keine CPAN Abhängigkeit.

[RichardCZ]

ist jetzt zwar OT , aber ich sehe da oben oft " with very long lines" , daher die Frage : ab wann ist eine Zeile very long ?

linux "file" command

https://www.linuxquestions.org/questions/linux-newbie-8/aboout-with-very-long-lines-how-long-is-very-long-4175417737/

300 bytes wohl. Da würde ich mir erstmal keine Sorgen drum machen.

[rudolfkoenig]

Tatsache ist, dass derzeit im Code kein einziges File ASCII ist.

Kannst Du bitte das belegen?
Ich wage zu behaupten, dass  "meine" Module ASCII sind, file ist auch der gleichen Meinung.

[RichardCZ]

Kannst Du bitte das belegen?
Ich wage zu behaupten, dass  "meine" Module ASCII sind, file ist auch der gleichen Meinung.

Du hast Recht, ich hatte ein falsches grep, Blutgruppe 0 gibt's auch.

$ file * | grep ASCII | wc -l
283
$ file * | grep -i utf-8 | wc -l
276
$ file * | grep -i 8859 | wc -l
26

Ändert jetzt nicht viel dran, dass die 26 x 8859er Ärger machen, auch nicht daran, dass der  "wenn &uuml;berpr&uuml;ft werden so" Fetisch selbst in den ASCII Files dann verschwinden könnte.

Ich habe das mit den Vorbehalten "unnötige Änderungen" in den Dateien zu machen schon verstanden, aber für mich ist z.B. das hier ne Sache von 30 Minuten - und bei mir kann ich das auch machen - nur leider wäre dann mein Repo ziemlich hoffnungslos vom FHEM Repo geforkt, weil das zwar triviale Änderungen sind, aber dann doch viele Zeilen in vielen Files betreffen.

[justme1968]

ich bin absolut dafür fhem komplett auf utf-8 umzustellen.

aber zu denken es ist mit 30 minuten und dem convertieren des modul quelltextes getan ist ein irrtum.

fhem verwendet intern aktuell für alle strings nur bytefolgen. nicht korrekt mit encoding markierte strings. das hat einfluss auf das verhalten jeder regex und jedem modul dad daten importiert oder exportiert.

wenn man das angeht und alle strings als tatsächlich utf-8 encoded verwendet verändert sich unter anderem das verhalten der aller möglichen regex. und das auch noch perl versions abhängig. dies lässt sich nicht automatisch und im vornherein testen.

dir alternative ist alles umzustellen und viel viel zeit und genervte anwender einzuplanen um das nach und nach wieder gerade zu ziehen. das muss man wollen und akzeptieren.

bitte nicht falsch verstehen: es geht nicht um das machen wir schon immer so. sondern um diese diskussion gab es schon mehr als ein mal und der aufwand ist sehr viel größer als es auf den ersten blick scheint.

ich fände ein fhem das komplett mit utf-8 arbeitet klasse.

[RichardCZ]

fhem verwendet intern aktuell für alle strings nur bytefolgen. nicht korrekt mit encoding markierte strings. das hat einfluss auf das verhalten jeder regex und jedem modul dad daten importiert oder exportiert.

Die Konversion des Encodings und der HTML Entities ist in < 30 Minuten getan.

Du hast Recht, dass es durchaus einige Probleme gibt, z.B. in den Regexen. Die gibt es aber jetzt schon. Es ist nicht korrekt, dass fhem jetzt für alle strings nur bytefolgen (octets) verwendet.

Da der Namespace unter "main" ein großer Kessel buntes ist, reicht es wenn nur ein einziges Modul "use utf8" macht.

Tadaaa:

Code Auswählen Erweitern

FHEM/98_MediaList.pm:use utf8;
FHEM/98_livetracking.pm:use utf8;
FHEM/70_Pushsafer.pm:use utf8;
FHEM/70_LaMetric2.pm:use utf8;
FHEM/70_VIERA.pm:use utf8;
FHEM/70_Pushover.pm:use utf8;
FHEM/70_Jabber.pm:use utf8;
FHEM/73_AutoShuttersControl.pm:use utf8;
FHEM/75_MSG.pm:use utf8;
FHEM/59_Wunderground.pm:use utf8;
FHEM/59_GSI.pm:use utf8;
FHEM/59_GSI.pm:use utf8;
FHEM/59_GSI.pm:use utf8;
FHEM/59_GSI.pm:use utf8;
FHEM/lib/UPnP/ControlPoint.pm:use utf8;
FHEM/60_allergy.pm:use utf8;
FHEM/Unit.pm:use utf8;
FHEM/Unit.pm:use utf8;
FHEM/26_tahoma.pm:use utf8;
FHEM/95_Astro.pm:use utf8;
FHEM/71_YAMAHA_MC.pm:            use utf8;
FHEM/71_YAMAHA_MC.pm:                use utf8;
FHEM/50_TelegramBot.pm:use utf8;
FHEM/73_DoorBird.pm:use utf8;
FHEM/UConv.pm:use utf8;
FHEM/70_Pushbullet.pm:use utf8;
FHEM/37_echodevice.pm:use utf8;
FHEM/00_SONOS.pm:                                       use utf8;
FHEM/00_SONOS.pm:               use utf8;
FHEM/00_SONOS.pm:                       use utf8;
FHEM/00_SONOS.pm:                       use utf8;

Witzigerweise machen einige iso-8859-1 kodierte Module "use utf8" - das ist schon ein wenig Realsatire.

Die Probleme in den Regexen bestehen z.B. darin, dass \d mehr macht als man zunächst glaubt.

ZERO:  0٠۰߀०০੦૦୦௦౦೦൦๐໐０
ONE:   1١۱߁१১੧૧୧௧౧೧൧๑໑１
TWO:   2٢۲߂२২੨૨୨௨౨೨൨๒໒２
THREE: 3٣۳߃३৩੩૩୩௩౩೩൩๓໓３
FOUR:  4٤۴߄४৪੪૪୪௪౪೪൪๔໔４
FIVE:  5٥۵߅५৫੫૫୫௫౫೫൫๕໕５
SIX:   6٦۶߆६৬੬૬୬௬౬೬൬๖໖６
SEVEN: 7٧۷߇७৭੭૭୭௭౭೭൭๗໗７
EIGHT: 8٨۸߈८৮੮૮୮௮౮೮൮๘໘８
NINE:  9٩۹߉९৯੯૯୯௯౯೯൯๙໙９

Das alles wird an einigen Stellen von \d gematched. Jetzt schon.

Ich halte die Vorsicht "nicht unnötig" im Code rumzupfuhlen schon für richtig, aber nach allem was ich so sehe ist der Code schon jetzt absolut nicht unter Kontrolle. Das Argument "funktioniert jahrelang" ist m.E. nicht gültig. Ich würde es ungern machen, aber ich glaube, dass man FHEM relativ schnell knacken kann mit "bösen" Eingaben/Daten.

Die von mir vorgeschlagenen Änderungen mögen unangenehm erscheinen, weil sie "Staub aufwirbeln", aber ich persönlich sehe das eher wie ne Desinfektion einer eitrigen Wunde an. Das ist auch unangenehm, aber besser man macht das als einfach nur ein großes Pflaster drüber.

Ich rede hier nicht als Perl Hacker, ich rede als Häuslebesitzer, Familienvater, der zu Hause lieber einen zuverlässigen Butler hätte als einen Geist aus der Lampe.

[justme1968]

use urf8 bezieht sich auf das encoding in dem das quelltext file geschrieben ist und auf strings die dort im klartext hinterlegt sind. es bezieht sich nicht auf strings die empfangen und gesendet bez gelesen und geschrieben werden. das das ist die überwiegende mehrzahl.

das problem ist nicht das \d mehr matched als man glaubt sondern das es unmöglich ist z.b. deutsche umlaute als solche hinzuschreiben und zu matchen wenn die stings nicht mit korrektem encoding markiert sind. und das perl versions übergreifend. deshalb und weil die fhem stings eben explizit nicht mit encoding markiert sind sondern als binäre byte strings behandelt werden hilft auch encode aktuell nich nicht.

ja. es gibt probleme mit der aktuellen implementierung. genau deshalb gab es diese diskussion ja schon mehrfach. unter anderem auch von mir. ich bin dafür alles in utf-8 zu machen.

aber ich sehe nicht das dies praktikabel ist so lange auch ältere perl versionen unterstützt werden sollen. die 30minuten reichen definitiv nicht. auch 10 mal so viel reicht nicht. und dann bleiben immer noch die alten module die aktuell keinen maintainer haben und potentiell problematisch sind und nicht ohne entsprechende hardware testbar.


ps: das böse eingaben argument hat hier nichts zu suchen. das ist komplet unabhängig vom encoding. hier ist die verwendete perl version relevant.

[justme1968]

noch mal: bitte nicht falsch verstehen. ich bin für utf-8. überall.

aber es ist definitiv nicht mit einem use utf8 in jedem file getan. ganz im gegenteil.

[RichardCZ]

Ich meine, Subversion erlaubt doch Branches.

Wenn ich commit-Rechte aufs SVN bekomme, könnte ich doch eine experimental/beta/bleeding-edge branch aufmachen und dort rumknödeln.
Im Gegensatz zu meinem Git, bestünde dann zumindest noch die Möglichkeit diese Änderungen zurückzumergen.

Oder - man geht den progressiveren Weg - es wird eine branch "classic" angelegt, die erstmal die bisherige Codebasis konservativ weiterführt, während diejenigen, die vielleicht mehr am Code machen wollen in trunk "abhausen".

Da ich ohnehin länger zu Hause im HomeOffice rumlungern werde, kann ich mich momentan anbieten solche "Aufräumarbeiten" zu machen. Das Konzept Code/Modulübergreifender Arbeiten ist im übrigen nicht so ungewöhnlich. Im Linux Kernel gibt es auch "Janitors", die sich im grunde jeden Code ansehen und diesen nicht hinsichtlich Funktionalität, sondern hinsichtlich Robustheit und Wartbarkeit durch die Mangel nehmen.

(Off-Topic: Bei mir habe ich z.B. alle Prototypes - bis auf einen - aus fhem.pl rausgeschmissen und FHEM läuft immer noch  )
https://gl.petatech.eu/root/FHEM/-/commit/5cb9934bda8122988382ae1217882768ad5adad3

[herrmannj]

Um das zu verifizieren müsstest du jedes Modul testen, was in den meisten Fällen ohne die entsprechenden Hardware device nicht geht

[RichardCZ]

use urf8 bezieht sich auf das encoding in dem das quelltext file geschrieben ist und auf strings die dort im klartext hinterlegt sind. es bezieht sich nicht auf strings die empfangen und gesendet bez gelesen und geschrieben werden. das das ist die überwiegende mehrzahl.

Zu Mehrzahl/nicht Mehrzahl kann ich noch nichts sagen, aber "use utf8" bezieht sich - und das war die Diskussion - vor allem darauf wie Perl reguläre Ausdrücke interpretiert. https://perldoc.perl.org/perlunicode.html

use utf8 still needed to enable UTF-8 in scripts
If your Perl script is itself encoded in UTF-8, the use utf8 pragma must be explicitly included to enable recognition of that (in string or regular expression literals, or in identifier names). This is the only time when an explicit use utf8 is needed. (See utf8).

Damit wollte ich nur sagen, dass ich sicher nicht ausschliesse, dass eine tabula rasa Änderung iso->utf-8 der restlichen Dateien, sowie ASCII->utf-8 derjenigen die HTML entities haben noch irgendwelche unerwünschten Seiteneffekte bringt.

Aber ich glaube, dass diese Seiteneffekte eher die Stellen offenbaren werden, wo man manuel irgendwelche utf8::upgrade Krücken verwendet hat. Und wenn man DAS ausmerzt, dann sollte das Ziel "alles hübsch in utf-8 zu haben" doch erreicht sein.

perl versions übergreifend.

Das ist nochmal ein anderes Fass, dass ich jetzt nicht auch noch aufmachen wollte, aber auch hier wäre zu überlegen, ob man nicht mittels

use v5.28.1;

die herde ein wenig antreibt.

https://www.cvedetails.com/vulnerability-list/vendor_id-1885/Perl.html

Die gute Nachricht ist, dass FHEM unter 5.30 problemlos tut.

aber ich sehe nicht das dies praktikabel ist so lange auch ältere perl versionen unterstützt werden sollen. die 30minuten reichen definitiv nicht. auch 10 mal so viel reicht nicht. und dann bleiben immer noch die alten module die aktuell keinen maintainer haben und potentiell problematisch sind und nicht ohne entsprechende hardware testbar.

Dann siehe meinen Vorschlag oben, "progressive" Branch mit encoding, prototypes, PBP, neuem Perl.
Weil ehrlich gesagt, ansonsten mache ich mir lieber mein eigenes FHEM, dann halt nur mit den Modulen die ich brauche. Das fände ich aber ziemlich schade - irgendwie finde ich wäre das nicht der Zweck der Übung.

[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.

[rudolfkoenig]

Bei 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.

die 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.

[herrmannj]

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.

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.

Genau! Zusätzlich zeigt die Erfahrung dass auch Seiteneffekte innerhalb von Modulen erst nach Monaten auffallen.

Edit: volle Zustimmung zu Rudis Beitrag!

[rudolfkoenig]

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.

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]

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 '&auml;' 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.

¯\_(ツ)_/¯

[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.

[rudolfkoenig]

Ok. 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]

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.

[herrmannj]

Ich 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:

eben 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

[viegener]

@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 ?

[RichardCZ]

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; &uml; statt &auml; ... verwendet

weitere mit dem gleichen Fehler:

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

Gern geschehen.

[RichardCZ]

In 00_SONOS bin ich dann mit ner Funktion

Code Auswählen Erweitern

sub SONOS_ConvertUmlautToHtml($) {
my ($var) = @_;

if ($var eq 'ä') {
return 'ä';
} elsif ($var eq 'ö') {
return 'ö';
} elsif ($var eq 'ü') {
return 'ü';
} elsif ($var eq 'Ä') {
return 'Ä';
} elsif ($var eq 'Ö') {
return 'Ö';
} elsif ($var eq 'Ü') {
return 'Ü';
} elsif ($var eq 'ß') {
return 'ß';
} else {
return $var;
}
}

konfrontiert. Glücklicher Weise wird die nirgends verwendet, also kann ich die ersatzlos streichen. Ist auch Fleißarbeit.
Sobald ich die gelöscht habe, wanderte mein Blick auf

Code Auswählen Erweitern

sub SONOS_UmlautConvert($) {
eval {                     ###### WOW
use utf8;        ###### Doppel WOW
my ($var) = @_;

if ($var eq 'ä') {
return 'ae';
} elsif ($var eq 'ö') {
return 'oe';
} elsif ($var eq 'ü') {
return 'ue';
} elsif ($var eq 'Ä') {
return 'Ae';
} elsif ($var eq 'Ö') {
return 'Oe';
} elsif ($var eq 'Ü') {
return 'Ue';
} elsif ($var eq 'ß') {
return 'ss';
} else {
return '_';
}
}
}

[herrmannj]

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 ?

Du, das ist genau das Mißverständniss. Um es klar zu sagen: es gibt keinen commit handler der das löst. ISO8859 / use UTF8 sind keine Lösung dafür.

Dein (ex) "Problem" hat etwas mit dem internen Informationsfluss in den modulen zu tun. Das muss man im Modul debuggen und das ist teilweise sehr schwer nachzuvollziehen. Die Lösung 'use UTF8' löst was anderes, aber eben nicht das. Da darf es jetzt auch keinen Zweifel geben Was aber möglich ist: durch unbedachte Änderungen an anderen Modulen (zb fhemweb, fhem.pl) kannst Du sehr wohl genau diese Baustelle in Deinem Modul (Telegram) wieder aufgemacht "bekommen".

[RichardCZ]

Du, das ist genau das Mißverständniss. Um es klar zu sagen: es gibt keinen commit handler der das löst. ISO8859 / use UTF8 sind keine Lösung dafür.

Dein (ex) "Problem" hat etwas mit dem internen Informationsfluss in den modulen zu tun. Das muss man im Modul debuggen und das ist teilweise sehr schwer nachzuvollziehen. Die Lösung 'use UTF8' löst was anderes, aber eben nicht das. Da darf es jetzt auch keinen Zweifel geben Was aber möglich ist: durch unbedachte Änderungen an anderen Modulen (zb fhemweb, fhem.pl) kannst Du sehr wohl genau diese Baustelle in Deinem Modul (Telegram) wieder aufgemacht "bekommen".

Der "interne Informationsfluss in den Modulen" (eine für mich an Esoterik grenzende Phrase), kann aber geradlinig sein (= "Ich bin UTF-8, und gehe per Default von UTF-8 am Ein- und Ausgang aus") oder er kann verzwickt - wie derzeit - sein. Mit Modulen in unterschiedlichen Encodings, und mit verschiedenen Heurismen die Encoding Probleme in den Griff zu bekommen (eval Blöcke in denen geglaubt wird temporär UTF-8 "anzuschalten") etc.
Das alles natürlich in einem gemeinsamen Namespace, mit den entsprechenden Seiteneffekten, jemand "fixt" etwas in "seinem" Modul, hat aber Effekte auf main.

Und ja, wenn man nicht keine Unmaßnahmen zur Nichtabschaffung unternimmt, dann wird es immer schwer nachvollziehbar sein - wie in etwa der Anfang dieses Satzes. Weil so in etwa sieht "der interne Informationsfluss" in den Modulen derzeit aus.

Kann einem das Zeug um die Ohren fliegen wenn man ein paar Negierungen rausschmeisst (und dabei einige vergisst)? Klar! Aber irgendwann (Fleissarbeit) sollte man mit der Situation belohnt werden, dass Probleme eben nicht mehr schwer nachzuvollziehen sind.

Dann könnten sich Entwickler auf evtl. spaßigere Features konzentrieren als "monatelang von irgendwelchen Phantomproblemen geplagt zu werden".

Aber hey! Wenn hier jemand unbedingt seine masochistische Ader ausleben will, ich werde ihn sicher nicht daran hindern.

[herrmannj]

Ich empfehle die Lektüre von:
https://perldoc.perl.org/perlunicode.html
https://perldoc.perl.org/utf8.html

Sind einzelne Konstrukte Mist (eval und use utf8)? Ja. Hilft use utf8? nein.

Der "Informationsfluss im modul" ist keinesfalls esoterisch sondern der real existierende Weg auf dem die Information von "Eingang" zur Ausgabe fliest. Auf diesem Weg wird sie mehrfach explizit oder implizit konvertiert und dieses (teilweise transparente) Verhalten unterscheidet sich leider (auch) je nach perl- oder os Version bzw ist von Bibliotheken abhängig. Implizite Konvertierungen werden beispielsweise vom Perl IO Layer oder JSON Bibliotheken durchgeführt. Explizit zum Beispiel durch convert.

Innerhalb von perl sind Strings, wenn man das nicht explizit ausschaltet, immer UNICODE strings (ungleich utf8). Auf dem Papier liest sich '= "Ich bin UTF-8, und gehe per Default von UTF-8 am Ein- und Ausgang aus")' super. Die Aussage unterschlägt aber dass dies der Normalfall ist. Da widerspricht Dir niemand, zumindest ich tu es nicht.

Das was Du siehst sind (von falscher Anwendung abgesehen ) genau die Ausnahmen bei denen die Theorie nicht mit der Praxis übereinstimmt weil eben irgendeine Bibliothek, eine perl Version (in Kombination mit einem bestimmten OS) sich leider nicht daran gehalten hat. Aufräumen ja, wenn Du verstehst was Du tust. Aufräumen weils in einen Buch steht? Nun ja.

[RichardCZ]

Ich empfehle die Lektüre von:
https://perldoc.perl.org/perlunicode.html
https://perldoc.perl.org/utf8.html

Ich gebe noch einmal zu bedenken, dass ich Perl aktiv seit 25 Jahren mache. Diese "Lektüreempfehlungen" wirken auf mich so, wie es auf Dich wirken würde, wenn ich Dir empfehlen würde noch einmal die Schule zu besuchen.

[Wzut]

weitere mit dem gleichen Fehler:
-- snipp ---
96_SIP.pm

Och Mensch gerade mal ein einziges falsches ü .... bis ich das gefunden hatte bin ich über drei Rechtschreibfehler und einen völlig verworrenen Satz gestolpert.
Da sieht man es wieder : kein Mensch liest die commandref   

[viegener]

Du, das ist genau das Mißverständniss. Um es klar zu sagen: es gibt keinen commit handler der das löst. ISO8859 / use UTF8 sind keine Lösung dafür.

Dein (ex) "Problem" hat etwas mit dem internen Informationsfluss in den modulen zu tun. Das muss man im Modul debuggen und das ist teilweise sehr schwer nachzuvollziehen. Die Lösung 'use UTF8' löst was anderes, aber eben nicht das. Da darf es jetzt auch keinen Zweifel geben Was aber möglich ist: durch unbedachte Änderungen an anderen Modulen (zb fhemweb, fhem.pl) kannst Du sehr wohl genau diese Baustelle in Deinem Modul (Telegram) wieder aufgemacht "bekommen".

Das ist mir beides durchaus klar

ad 1) Es gäbe ja durchaus Vorteile, einige der angesprochenen Unzulänglichkeiten zu lösen, der Commithandler ist keine Lösung aber ein Schritt in eine Richtung

ad 2) Mir ist die Lösung meines (ex-)Problem durchaus klar und Ja, "use utf-8" hilft hier eher nicht. Aber nein, debuggen hilft nicht, denn es gibt dazu einfach zuviele Varianten von perl+JSON+OS+etc.

[RichardCZ]

Ist man sich sicher, dass das hier tut? &amp;uuml;

33_readingsGroup.pm:        attr heizung mapping {'t1.temperature' => 'Vorlauf', 't2.temperature' => 'R&amp;uuml;cklauf', 't3.temperature' => 'Zirkulation'}<br>
33_readingsGroup.pm:        attr heizung mapping {'t1.temperature' => 'Vorlauf', 't2.temperature' => 'R&amp;uuml;cklauf', 't3.temperature' => 'Zirkulation'}<br>

&aauml; auch eher nicht

57_Calendar.pm:                  Das folgende realisiert eine HTML Anzeige f&uuml;r die n&aauml;chsten Abholungstermine:<br><br>

&auuml; auch nicht und dann noch -> ausfegührten typo

73_ElectricityCalculator.pm:                            Sollten die unten ausfeg&auuml;hrten Attribute bei der Definition eines entsprechenden Gerätes nicht gesetzt sein, so werden sie vom Modul mit Standard Werten automatisch gesetzt<BR>

73_GasCalculator.pm
73_WaterCalculator.pm

dito (es lebe die Deduplizierung)

[justme1968]

für die readingsgroup doku: ja.

der 'quelltext' ('R&amp;uuml;cklauf') wird in der generierten dokumentation zu ... =>'R&uuml;cklauf', ... (siehe z.b. hier: https://fhem.de/commandref.html) und das ist dann das was im attribut angeben muss um ganz am ende Rücklauf im browser stehen zu haben wenn man die fhemweb aufruft.

das beispiel ist noch aus der zeit als die eingabe eines utf-8 umlauts per telnet noch nicht möglich war. inzwischen geht das aber und man könnte in der doku auch direkt 'R&uuml;cklauf' schreiben um zu sagen das man 'Rücklauf' eingeben kann.

gleiches gilt für das &amp;deg;C ein paar Zeilen weiter unten.