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.