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

[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? ü

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.