FB_Calllist Character Fehler

[CoolTux]

Hallo zusammen,

da ich nach weiteren Recherchen keine Erkenntnisse sammeln konnte, warum dieses Verhalten von strftime() sich geändert hat, habe ich nun meinen Workaround eingecheckt. Nun habe ich in allen Perl-Versionen funktionierende Sonderzeichen.

Gibts ab morgen via update.

Viele Grüße

Markus

Gerade getestet. Klappt wunderbar bei mir. Ich danke Dir sehr.



Grüße

[Markus Bloch]

müssten das dann nicht eigentlich mehrere module haben??
momentan ist ja märz

Nur wenn sie den Monatsnamen in Textform mit deutscher Sprache dabei verwenden. In der Regel ist das aber nicht der Fall, weil bspw. nur %d.%m.%Y gemacht wird um 08.03.2018 zu erhalten und das meistens in der Default-Locale "C" oder "en_EN.UTF-8".

Das Problem tritt ja nur auf, wenn in diesen Modulen bei strftime() der Platzhalter "%b" (Mär) oder "%B" (März) bei gesetzter deutscher Sprache (de_DE.UTF-8) verwendet wird. Und das macht mWn keines der Module außer FB_CALLLIST ohne es jedoch genau verifizert zu haben.

Daher bin ich leider der einzige.

Gruß
Markus

[CoolTux]

Es kommt drauf an wie Du das Datum haben willst.
Vielleicht wollen die anderen Module den Monat nicht als Wort.



Edit: Markus war schneller

[nils_]

Nur wenn sie den Monatsnamen in Textform mit deutscher Sprache dabei verwenden. In der Regel ist das aber nicht der Fall, weil bspw. nur %d.%m.%Y gemacht wird um 08.03.2018 zu erhalten und das meistens in der Default-Locale "C" oder "en_EN.UTF-8".

Das Problem tritt ja nur auf, wenn in diesen Modulen bei strftime() der Platzhalter "%b" (Mär) oder "%B" (März) bei gesetzter deutscher Sprache (de_DE.UTF-8) verwendet wird. Und das macht mWn keines der Module außer FB_CALLLIST ohne es jedoch genau verifizert zu haben.

ok, daran habe ich nicht gedacht

Daher bin ich leider der einzige.

ja scheint so zu sein

mit

Code Auswählen Erweitern

grep -rl strftime\(.*%b *
kommt nur

Code Auswählen Erweitern

72_FB_CALLLIST.pm
raus.

bei

Code Auswählen Erweitern

grep -rl strftime\(.*%B *
kommt nichts.


bin mir aber nicht sicher, ob der regex so wirklich richtig gewählt ist 

[peter-s]

Hi,

sorry, hatte nicht vor so eine riesen Diskussion loszutreten! 

Auf jeden Fall hat die Änderung Markus geholfen, nach einem Update sieht die Liste wieder gut aus!
Vielen Dank!!!

LG Peter

[Markus Bloch]

sorry, hatte nicht vor so eine riesen Diskussion loszutreten! 

Ist doch kein Problem. Wenn ich es bei mir nicht nachstellen kann, muss man eruieren was bei mir anders ist als bei euch. Das bedarf schonmal ein paar Beiträgen bis man eine passende Lösung findet.

Gruß
Markus

[justme1968]

@markus: ich bin für readingsHistory eben auf das gleiche problem hingewiesen worden und habe erst mal einfach deinen workaround kopiert da es ja scheinbar hilft.

aber mir fallen zwei dinge auf:
- du verwendest zum ersetzen utf8 umlaute. eigentlich gehört ja jetzt ein use utf8 in den code
- wäre es nicht besser umlaute als 2 byte sequenz in \x notation anzugeben?
  das wäre dann konsistent mit der sonstigen fhem internen darstellung.

gruss
  andre

[CoolTux]

Ich hatte vor kurzem beim DarkSkyAPI und OpenWeatherMapAPI Modul das selbe Problem. Habe mich auch erstmal bei Markus bedient. 

Nur zur Info

[justme1968]

dann sollten wir vielleicht eine zentrale version bauen und rudi zum einchecken geben.

[CoolTux]

Bin ich dabei.
Frage: Wieso use utf8, das bringt doch nur was wenn Du ein externes Modul verwenden willst, oder?


Grüße

[justme1968]

wenn im quelltext utf8 verwendet wird gehört eigentlich ein use utf8 an den anfang. sonst weiss der perl interpreter nicht in welchem encoding er das file interpretieren soll.

das es hier ohne geht liegt vermutlich daran das fhem zwar utf8 als string encoding verwendet aber ohne diese auf perl ebene als solche zu markieren sondern sie einfach als byte sequenz ansieht.

[CoolTux]

wenn im quelltext utf8 verwendet wird gehört eigentlich ein use utf8 an den anfang. sonst weiss der perl interpreter nicht in welchem encoding er das file interpretieren soll.

das es hier ohne geht liegt vermutlich daran das fhem zwar utf8 als string encoding verwendet aber ohne diese auf perl ebene als solche zu markieren sondern sie einfach als byte sequenz ansieht.

Ah alles klar. Dann weiß ich was ich in Zukunft zu tun habe.
In wie fern willst Du den vorhanden Code ändern?

Code Auswählen Erweitern


$string =~ s/\xe4/ä/g;
    $string =~ s/\xc4/Ä/g;
    $string =~ s/\xf6/ö/g;
    $string =~ s/\xd6/Ö/g;
    $string =~ s/\xfc/ü/g;
    $string =~ s/\xdc/Ü/g;
    $string =~ s/\xdf/ß/g;
    $string =~ s/\xdf/ß/g;
    $string =~ s/\xe1/á/g;
    $string =~ s/\xe9/é/g;
    $string =~ s/\xc1/Á/g;
    $string =~ s/\xc9/É/g;


[justme1968]

achtung. es kann sein das es gerade wegen der kombination ohne use utf8 und utf8 zeigen geht.

eigentlich wäre es in der art für fhem richtiger:

Code Auswählen Erweitern

$string =~ s/\xe4/\xc3\x96/g;
d.h. als zwei einzelne byte.

das 'problem' ist das fhem intern zwar utf8 verwendet aber keine 'echten' perl utf8 strings sondern nur die utf8 byte folge.

das ganze ist leider ziemlich kompliziert und es spielen alle möglichen dinge mit rein von perl version über schalten der io kanäle auf utf8 bis hin zum richtigen matchen von umlauten in regex.

bei so vielen variablen gegebenheiten, historischen randbedingungen und installationen wie wir sie in fhem haben gibt es vermutlich die 'ein und einzige richtige lösung' nicht.

[CoolTux]

Dann sollten wir schauen das wir eine eventuelle Funktion nicht in fhem.pl sondern als kleine Hilfsfunktion in 99_Utils.pm unterbringen.