Das längste Thema

    Ich bin heute schon länger einem komischen Bug auf der Spur.

    Das Setting:

    Ich hoste eine Owncloud selbst. Auf einem Server liegt ein selbst gebastelter Webdav client, der mir Files zur Cloud hin synced. Dafür ruft er die Liste der Files in Ordner XY ab und vergleicht die mit dem lokalen Dateisystem.

    Heute kam es dann vor, dass eine Datei unendlich oft hochgeladen wurde, obwohl sie bereits existierte.

    Der Grund dafür, die File auf dem Dateisystem hatte ein ü im Namen. Um genau zu sein, ein normales u mit diesem Unicode-Zeichen "dahinter".

    Da hab ich erst mal nicht schlecht gestaunt und dann einen Bug in meinem Script vermutet, kann ja mal vorkommen, sowas hatte ich damals sicher nicht auf dem Schirm.

    Jetzt, 2 Stunden später, bin ich um einiges Schlauer. Der Bug liegt nicht in meinem Script, sondern in der Owncloud, bzw im darunter liegenden Symfony Framework. Es ist auch nicht wirklich ein Bug, es scheint ein gewolltes verhalten zu sein.

    In Zeile 54 der File canonicalComposition.php wird das "falsche" ü zum "normalen" ü gemacht, welches man auch über die Tastatur erzeugen kann.

    Nun hat mein Script natürlich das Problem, dass der Filename nicht mehr matched, wenn es prüft, ob die Datei schon in meiner Cloud exisitert..

    Da frage ich mich, selbst professioneller PHP Entwickler, wieso? Wieso den Wert nicht "as-is" lassen und einfach damit umgehen, was der User rein wirft? Jetzt muss ich in meinem Script auch eine solche Tabelle zur "Übersetzung" anlegen.

    Falls es interessiert:

    "normales" ü, url encodiert: %C3%BC, UTF-8 Char: 00FC

    "falsches" ü, url encodiert: u%CC%88, u + UTF-8 Char: 0308

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

    Vielleicht tragt ja das hier dazu bei zu verstehen, warum das passiert: https://de.wikipedia.org/wiki/Normalisierung_(Unicode)

    Einmal editiert, zuletzt von tab (24. September 2022 um 02:26)

    Zitat von tab

    Vielleicht tragt ja das hier dazu bei zu verstehen, warum das passiert: https://de.wikipedia.org/wiki/Normalisierung_(Unicode)

    Danke für den Hinweis :) Ich habe mich da auch schon mit Kollegen dazu unterhalten. Ich verstehe den Ansatz der hier verfolgt wird. (Damit z.B. die Volltext-Suche das einheitlich erkennt).

    Ich als Entwickler hätte allerdings ein Problem damit, die Datei im Original zu manipulieren. Da ich eben selbst auch von der Software erwarten würde, dass ich sie 1:1 wieder raus bekomme, wie ich sie rein geschoben habe. Diese Anpassung im Namen (mal am Beispiel der Volltext-Suche) hätte man ja auch nur im suchindex machen können. Oder als Alias in der DB anlegen.

    Wo man da jetzt die Wurzel des Problems sucht, ist natürlich auch wieder eine Frage der Ansicht. Den Text mit dem "falschen" ü erhalte ich von der YouTube-API. Dort wird das wohl nicht Normalisiert oder eben wieder zurück-gewandelt für die Ausgabe.

    Man könnte es natürlich auch so sehen, dass YouTube schon diese Eingabe normalisieren sollte und es auch überall entsprechend ausgeben sollte.

    So muss ich jetzt halt auch solch eine Tabelle in meinem Programm pflegen. Was nicht notwendig gewesen wäre, wenn entweder YouTube oder die Ownlcoud das anders handhaben würden..

    Beruflich arbeite ich im Backend-Development und habe bei einem Kunden viel mit APIs von 20-30 verschiedenen Firmen zutun. Da nutzt natürlich auch jeder ein anderes System und niemand ist sich einig. Das Problem an sich ist mir nicht fremd. Trotzdem nervt es mich jedes mal aufs neue, wenn ich deswegen irgendwo konvertieren muss ^^

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

    Zitat von H6G

    Unicode in Dateinamen halte ich für eine schlechte Idee.

    Via CLI macht das sowieso keinen Spaß.

    Warum das so ist, siehst du in der Datei /home/h6g/Dokumente/💩 Geschäftsbericht 2021/ Unicode.txt

    Ich erhalte die Daten von einer anderen API und wollte alles möglichst "as-is" durchgeben. In dem Teil des Dateisystems bin ich selbst mit der CLI zum Glück nie unterwegs. Und falls doch, verwende ich häufig <TAB>, so muss ich mir zumindest um die Unicode Zeichen in der Mitte der Dateinamen keine Sorgen machen :D

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

    Ich habe hier schon wieder ein Thema mit dem Support bei dem ich wieder an ein Feature Request erinnert wurde und wollte mal bei [netcup] Claudia H. nachfragen ab wann man endlich abweichende "Techniker" Mailadressen im CCP eingeben kann. Ein weiteres Email-Feld kann doch keine Raketenwissenschaft sein die bald 2 Jahre auf Umsetzung wartet. Aktuell erreicht mich:

    Guten Tag,

    vielen Dank für Ihre Nachricht.

    Leider können wir Ihre Anfrage aus Datenschutzgründen nicht bearbeiten, da sie nicht von Ihrer im Customer Control Panel (CCP) registrierten E-Mail versendet wurde.

    Wir bitten Sie darum, die Nachricht entweder von der bei uns hinterlegten E-Mail-Adresse erneut zu versenden, oder diese im CCP zu ändern. Sie können auch das Kontaktformular im CCP zur Kontaktaufnahme nutzen.

    Okay sich strikt an den Standard halten ist das eine, aber eine Plus-Adresse abzulehnen die nur zu meinem Postfach gehören kann... Man sollte jedem Supportmitarbeiter so viel Kompetenz zusprechen, entscheiden zu können das meinemail+netcup@domain.tld eine Adresse von dem Kunden selbst ist. Die Plus-Adresse ist ja nur für einfachere Regeln ins Leben gerufen worden und Matchen auch noch genau den Namen des Arbeitgebers des Supportmitarbeiters. Etwas mehr Flexibilität wäre schön, andere können das auch. Zumal: Wenn ich das Ticket über das CCP erstelle, wieso sollte ich das dann fachlich fundiert beantworten wenn die falsche Mail hinterlegt ist und ich sie somit fälschlicherweise erhalten und eigentlich keine Kenntnis über den Vorgang habe.

    Ich geh dann ma Aliasse im Mailprogramm konfigurieren... #excusemewirhaben2022

    Zitat von sla

    Die Plus-Adresse ist ja nur für einfachere Regeln ins Leben gerufen worden ...

    es handelt sich dabei dennoch nur um eine "Kann"-Bestimmung, wenn man es so will; ein Mail-Server muss das nicht so handhaben;

    im Postfix ist auch sowas möglich: recipient_delimiter = -, dann wird das mit einem '-' abgehandelt; ein anderer Mailserver weiß von dem nichts;

    darum

    Achtung: auch wenn man hier ein '+' verwendet, muss das ein anderer Mailserver nicht honorieren; es sind dann echt 2 unterschiedliche Mail-Adressen, welche

    in keinem Zshg. stehen; so gesehen, handhabt das netcup auch korrekt;

    interessant zu dieser Thematik/Problematik:

    https://blog.tinned-software.net/configure-address-extension-in-postfix/

    bzw.

    https://fvdm.com/code/plus-address-forwarding-in-postfix

    hatten wir lange in der Arbeit diskutiert, wir mussten 2 Abtlg.en fusionieren und dachten dabei an sowas wie abt-ort1+ort2@domain

    und hatten das genau wegen der doch ominösen '+' Geschichte verworfen und kamen zum Schluß abt-ort1-ort2@domain als E-mailadresse zu vergeben;

    Grüße / Greetings

    Walter H.

    RS, VPS, Webhosting - was man halt so braucht;)

    Einmal editiert, zuletzt von mainziman (25. September 2022 um 15:05)