Hallo, > - Was macht TCPDF mit dem übergebenen String, d.h. wie heißt die Datei nachher auf der Platte? > - Was macht der Webserver, wenn er die URL M%C3%BCller_300522.pdf auf's Dateisystem mappen soll? und - transformiert oder interpretiert das Filesystem auch noch irgendwas? > Wenn der Browser das PDF abholen soll, muss das ü auf jeden Fall URL-codiert sein. Ob es richtig ist, es UTF-8 zu codieren, ist aber eine andere Frage - das hängt dann davon ab, ob der Dateiname UTF-8 codiert im Dateisystem des Servers abgelegt wurde. Korrekt. > Ich glaube, dass hier massive Systeminkompatibilitäten (Server-Betriebssystem, Server-Filesystem, Webserver-Software) lauern können. Ja, wobei gerade das Filesystem interessant ist. Unix/Linux-Filesysteme sind da phlegmatisch. Sie übernehmen einfach die Byte-Sequenz, die die Anwendung übergibt, und fragen nicht nach der Zeichencodierung. Die Shell allerdings schon, die geht von der im eingestellten *locale* festgelegten Zeichencodierung aus. Zeitgemäße Windows-Filesysteme (also NTFS) speichern Dateinamen in UCS-2, eine Untermenge von UTF-16. Das Filesystem-API gibt's doppelt - einmal für Strings in einer 8bit-Codierung (typischerweise Windows-1252, kann aber je nach lokalisierter Version auch was anderes sein), einmal für Strings in UCS-2. Wir wissen weder, welches der beiden APIs eine Anwendung (Webserver) verwendet, noch welche Codierung tatsächlich bei der 8bit-Variante zum Einsatz kommt. Es ist also ein Lottospiel. Ältere Windows-Filesysteme, also FAT (FAT12, FAT16, FAT32) speichern Dateinamen nur in einer 8bit-Codierung. Das dürfte aber heute höchstens noch auf externen Datenträgern zum Einsatz kommen (Speicherkarten von Digitalkameras oder Handies; externe Festplatten, die auf höchstmögliche Kompatibilität formatiert sind; USB-Sticks, die "überall" funktionieren müssen). > Hier, bei mir, im Edge-Browser unter Windows 10 gegen einen IIS Webserver, der auf dem gleichen Windows 10 mit NTFS läuft, kann ich eine Datei Müller.txt unter den Namen Müller.txt, M%FCller.txt und M%C3%BCller.txt abrufen. Das hätte ich nicht erwartet. > Irgendwie errät er das. Ja, it's magic. > Ob das mit einem Safari auf einen iPhone, der mit einem Apache unter Hinz-Linuchs mit Kunz-FS 47.11 läuft, das gleiche Verhalten zeigt - tjaaaaa. Es ist inzwischen gängige Praxis, dass nicht-ASCII-Zeichen in URLs in UTF-8 codiert werden. Normativ festgeschrieben ist das meines Wissens nicht. Einen schönen Tag noch  Martin -- Was ist der schnellste Weg von einem Suchtreffer zum nächsten? Ein Googlehupf.

Hallo, > - Was macht TCPDF mit dem übergebenen String, d.h. wie heißt die Datei nachher auf der Platte? > - Was macht der Webserver, wenn er die URL M%C3%BCller_300522.pdf auf's Dateisystem mappen soll? und - transformiert oder interpretiert das Filesystem auch noch irgendwas? > Wenn der Browser das PDF abholen soll, muss das ü auf jeden Fall URL-codiert sein. Ob es richtig ist, es UTF-8 zu codieren, ist aber eine andere Frage - das hängt dann davon ab, ob der Dateiname UTF-8 codiert im Dateisystem des Servers abgelegt wurde. Korrekt. > Ich glaube, dass hier massive Systeminkompatibilitäten (Server-Betriebssystem, Server-Filesystem, Webserver-Software) lauern können. Ja, wobei gerade das Filesystem interessant ist. Unix/Linux-Filesysteme sind da phlegmatisch. Sie übernehmen einfach die Byte-Sequenz, die die Anwendung übergibt, und fragen nicht nach der Zeichencodierung. Die Shell allerdings schon, die geht von der im eingestellten *locale* festgelegten Zeichencodierung aus. Zeitgemäße Windows-Filesysteme (also NTFS) speichern Dateinamen in UCS-2, eine Untermenge von UTF-16. Das Filesystem-API gibt's doppelt - einmal für Strings in einer 8bit-Codierung (typischerweise Windows-1252, kann aber je nach lokalisierter Version auch was anderes sein), einmal für Strings in UCS-2. Wir wissen weder, welches der beiden APIs eine Anwendung (Webserver) verwendet, noch welche Codierung tatsächlich bei der 8bit-Variante zum Einsatz kommt. Es ist also ein Lottospiel. Ältere Windows-Filesysteme, also FAT (FAT12, FAT16, FAT32) speichern Dateinamen nur in einer 8bit-Codierung. Das dürfte aber heute höchstens noch auf externen Datenträgern zum Einsatz kommen (Speicherkarten von Digitalkameras oder Handies; externe Festplatten, die auf höchstmögliche Kompatibilität formatiert sind; USB-Sticks, die "überall" funktionieren müssen). > Hier, bei mir, im Edge-Browser unter Windows 10 gegen einen IIS Webserver, der auf dem gleichen Windows 10 mit NTFS läuft, kann ich eine Datei Müller.txt unter den Namen Müller.txt, M%FCller.txt und M%C3%BCller.txt abrufen. Das hätte ich nicht erwartet. > Irgendwie errät er das. Ja, it's magic. > Ob das mit einem Safari auf einen iPhone, der mit einem Apache unter Hinz-Linuchs mit Kunz-FS 47.11 läuft, das gleiche Verhalten zeigt - tjaaaaa. Es ist inzwischen gängige Praxis, dass nicht-ASCII-Zeichen in URLs in UTF-8 codiert werden. Normativ festgeschrieben ist das meines Wissen nicht. Einen schönen Tag noch  Martin -- Was ist der schnellste Weg von einem Suchtreffer zum nächsten? Ein Googlehupf.

Hallo, > - Was macht TCPDF mit dem übergebenen String, d.h. wie heißt die Datei nachher auf der Platte? > - Was macht der Webserver, wenn er die URL M%C3%BCller_300522.pdf auf's Dateisystem mappen soll? und - transformiert oder interpretiert das Filesystem auch noch irgendwas? > Wenn der Browser das PDF abholen soll, muss das ü auf jeden Fall URL-codiert sein. Ob es richtig ist, es UTF-8 zu codieren, ist aber eine andere Frage - das hängt dann davon ab, ob der Dateiname UTF-8 codiert im Dateisystem des Servers abgelegt wurde. Korrekt. > Ich glaube, dass hier massive Systeminkompatibilitäten (Server-Betriebssystem, Server-Filesystem, Webserver-Software) lauern können. Ja, wobei gerade das Filesystem interessant ist. Unix/Linux-Filesysteme sind da phlegmatisch. Sie übernehmen einfach die Byte-Sequenz, die die Anwendung übergibt, und fragen nicht nach der Zeichencodierung. Die Shell allerdings schon, die geht von der im eingestellten *locale* festgelegten Zeichencodierung aus. Zeitgemäße Windows-Filesysteme (also NTFS) speichern Dateinamen in UCS-2, eine Untermenge von UTF-16. Das Filesystem-API gibt's doppelt - einmal für Strings in einer 8bit-Codierung (typischerweise Windows-1252, kann aber je nach lokalisierter Version auch was anderes sein), einmal für Strings in UCS-2. Wir wissen weder, welches der beiden APIs eine Anwendung (Webserver) verwendet, noch welche Codierung tatsächlich bei der 8bit-Variante zum Einsatz kommt. Es ist also ein Lottospiel. > Hier, bei mir, im Edge-Browser unter Windows 10 gegen einen IIS Webserver, der auf dem gleichen Windows 10 mit NTFS läuft, kann ich eine Datei Müller.txt unter den Namen Müller.txt, M%FCller.txt und M%C3%BCller.txt abrufen. Das hätte ich nicht erwartet. > Irgendwie errät er das. Ja, it's magic. > Ob das mit einem Safari auf einen iPhone, der mit einem Apache unter Hinz-Linuchs mit Kunz-FS 47.11 läuft, das gleiche Verhalten zeigt - tjaaaaa. Es ist inzwischen gängige Praxis, dass nicht-ASCII-Zeichen in URLs in UTF-8 codiert werden. Normativ festgeschrieben ist das meines Wissen nicht. Einen schönen Tag noch  Martin -- Was ist der schnellste Weg von einem Suchtreffer zum nächsten? Ein Googlehupf.