57_Calendar - Umlaute in URL können problematisch sein

[rob]

Hallo.

Ich habe einen Abfallkalender ähnlich diesem definiert:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

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

Da ich nicht in der Mühlstraße wohne, habe ich kein akutes Problem  . Nix eiliges also. Mit Tests kann ich gerne unterstützen, falls Bedarf bestünde.

VG
rob

[Dr. Boris Neubert]

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

[rob]

Hi Boris.

Vielen Dank für Deine flinke Rückmeldung.

Bei der Menge an Anwendern musste dieser doofe Randfall ja mal irgendwann auftreten.

Bisher nur hypothetisch 

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

[betateilchen]

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.

[Dr. Boris Neubert]

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 

[betateilchen]

*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 

[Dr. Boris Neubert]

[OT]

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]

[betateilchen]

[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 

[abc2006]

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

Code Auswählen Erweitern

https://www.fes-frankfurt.de/abfallkalender/QWxsZXNpbmFzdHIufDZ8NjU5MzE%3D.ics

Wenn ich die ändere in :

Code Auswählen Erweitern

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

[betateilchen]

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

[betateilchen]

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

[rudolfkoenig]

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.

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.