Hallo.
Ich habe einen Abfallkalender ähnlich diesem definiert:
define myCalender Calendar ical url https://web.c-trace.de/augsburglandkreis/abfallkalender/cal?Gemeinde=Ellgau&Ort=Ellgau&Strasse=Mühlstraße&Hausnr=6&Jahr=%Y&abfall=9|2|3|4|8| 82800
Die Umlaute in "Mühlstraße" u.ä. generieren diesen Log-Eintrag:
2023.02.24 11:16:21 1: Encoding problem in data/header (not UTF-8), check Forum #131207
Deshalb hatte ich das in dem Fred entspr. bekannt gemacht (https://forum.fhem.de/index.php/topic,131207.msg1265267.html#msg1265267 (https://forum.fhem.de/index.php/topic,131207.msg1265267.html#msg1265267)).
Hat erstmal nix mit 57_Calendar zu tun. Und bereits gefixt. Anscheinend gibt es zusätzlich ein Thema bei der URL-Kodierung, weshalb ich das hier kurzerhand rückmelde (s. https://forum.fhem.de/index.php/topic,131207.msg1265299.html#msg1265299 (https://forum.fhem.de/index.php/topic,131207.msg1265299.html#msg1265299)).
Da ich nicht in der Mühlstraße wohne, habe ich kein akutes Problem ;D. Nix eiliges also. Mit Tests kann ich gerne unterstützen, falls Bedarf bestünde.
VG
rob
Hallo,
es gibt die Möglichkeit, das Attribut quirks mit noWildcards an myCalender zu setzen, damit die sich aus der eigentlich erforderlichen URL-Kodierung von ü und ß ergebenden % nicht expandiert werden.
Dann wird natürlich das %Y nicht mehr zum Jahr expandiert.
Bei der Menge an Anwendern musste dieser doofe Randfall ja mal irgendwann auftreten. Ich wüsste aber auch nicht, wie eine praktikable Lösung stattdessen aussehen könnte.
Viele Grüße
Boris
Hi Boris.
Vielen Dank für Deine flinke Rückmeldung.
Zitat von: Dr. Boris Neubert am 02 März 2023, 12:31:02
Bei der Menge an Anwendern musste dieser doofe Randfall ja mal irgendwann auftreten.
Bisher nur hypothetisch :D
Mal laienhaft gefragt: könnte die Expansion von "%Y" für solche Randfälle nicht auf ein alternatives Zeichen umgestellt werden z.B. #Y?
Hoffe die Frage ist nicht ganz doof :-[
Allerdings macht es m.E. keinen großen Sinn ohne konkrete Betroffenheit Aufwand zu investieren. Dokumentiert ist es ja schon.
VG
rob
Man kann ja als Anwender in so einem Fall einfach die nächste Querstraße aussuchen, die hoffentlich keine Umlaute enthält.
Generell ist es bei solchen Abfallkalender-URLs eher unüblich, dass Straßennamen im Klartext auftauchen, bei uns steht da zum Beispiel eine Nummer.
Vermutlich ist dieser Effekt deshalb noch nicht als großes Problem in Erscheinung getreten.
Zitat von: rob am 02 März 2023, 12:44:36
Mal laienhaft gefragt: könnte die Expansion von "%Y" für solche Randfälle nicht auf ein alternatives Zeichen umgestellt werden z.B. #Y?
Wir benutzen eine zentrale Routine in fhem,pl: ResolveDateWildcards*, die - natürlich -
strftime() dafür einsetzt.
Der Aufwand lohnt einfach nicht.
*Die ersetzt auch noch %L durch das aktuelle logdir, das ist jetzt ein überraschender Hack ???
Zitat von: Dr. Boris Neubert am 02 März 2023, 14:00:22
*Die ersetzt auch noch %L durch das aktuelle logdir, das ist jetzt ein überraschender Hack ???
Naja, nur dann überraschend, wenn man %L noch nicht verwendet hat. Aber %L ist schon sehr alt in FHEM.
Um Dich nochmal zu überraschen: es gibt sogar eine Stelle in FHEM, da wird auch %Q (durch eine laufende Nummer) ersetzt 8)
[OT]
Zitat von: betateilchen am 02 März 2023, 15:40:15
Naja, nur dann überraschend, wenn man %L noch nicht verwendet hat. Aber %L ist schon sehr alt in FHEM.
Ich verwende %L auf der Nutzerseite. Überrascht hat mich, die Ersetzung in einer Funktion zu finden, die
ResolveDateWildcards heißt. Kann es natürlich verstehen, weil beides ja bei den Dateinamen von Logs gebraucht wird. Ich kann ja mal einen Patch einreichen zur Umbenennung in
ResolveWildcards ;)
[/OT]
Zitat von: Dr. Boris Neubert am 02 März 2023, 16:28:49
[OT]
Überrascht hat mich, die Ersetzung in einer Funktion zu finden, die ResolveDateWildcards heißt.
[/OT]
Das ist wohl eines der historischen gewachsenen "Geheimnisse" von FHEM.
Es gibt ja auch ein Modul namens "Blocking.pm", dessen Funktion "BlockingCall()" man dazu verwendet,
non-blocking zu arbeiten 8)
Moin,
kann einen weiteren Fall dazu beisteuern. Soll auch (nachdem ich das oben gelesen habe) kein Report sein, sondern nur eine "Info über ein weiteres auftreten", welches allerdings nicht an einem Umlaut zu hängen scheint: hier wird wohl ein "=" codiert ...
Mein Müllkalender hat die URL
https://www.fes-frankfurt.de/abfallkalender/QWxsZXNpbmFzdHIufDZ8NjU5MzE%3D.ics
Wenn ich die ändere in :
https://www.fes-frankfurt.de/abfallkalender/QWxsZXNpbmFzdHIufDZ8NjU5MzE=.ics
funktioniert es.
OT: Was mich gerade noch vor ein Rätsel stellt: Die Kalender für Hausnummer 5 und 6 haben (reproduzierbar) die gleiche URL. Aber die Hausnummer in den Terminen ist unterschiedlich/jeweils die richtige ...
Zitat von: abc2006 am 15 Mai 2023, 15:58:28welches allerdings nicht an einem Umlaut zu hängen scheint: hier wird wohl ein "=" codiert ...
Irgendwo in den Tiefen der FHEM Dokumentation steht m.E. geschrieben, dass man Prozentzeichen (und $ auch, wenn ich mich recht erinnere) im DEF doppeln muss.
Wenn das stimmt, sollte "https://www.fes-frankfurt.de/abfallkalender/QWxsZXNpbmFzdHIufDZ8NjU5MzE%%3D.ics" eigentlich funktionieren.
Zitat von: abc2006 am 15 Mai 2023, 15:58:28OT: Was mich gerade noch vor ein Rätsel stellt: Die Kalender für Hausnummer 5 und 6 haben (reproduzierbar) die gleiche URL.
Bist Du sicher?
5: /abfallkalender/QWxsZXNpbmFzdHIufDV8NjU5MzE%3D.ics
6: /abfallkalender/QWxsZXNpbmFzdHIufDZ8NjU5MzE%3D.ics
ZitatIrgendwo in den Tiefen der FHEM Dokumentation steht m.E. geschrieben, dass man Prozentzeichen (und $ auch, wenn ich mich recht erinnere) im DEF doppeln muss.
Fuer featuerelevel <= 5.6 wird vor dem Ausfuehren eines Codestueckes (wie ein perl-Einzeiler bei Notify) % mit dem Event und @ mit dem Devicenamen ersetzt.
Um das zu vermeiden, konnte man diese Zeichen doppeln (%% bzw. @@).
Beschrieben ist das hier: https://fhem.de/commandref_modular.html#notify
Ich hoffe, dass niemand der hier Fragen stellt FHEM 5.6 verwendet, oder "attr global featurelevel 5.6" setzt.
Da der fragliche String nicht ausgefuehrt wird, ist das in diesem Fall aber egal.
Die Ursache des beschriebenen Problems liegt eher daran, dass das Calendar Modul URL-Escape selbst nochmal anwendet.