Umlaute in Dateinamen

[tsunami]

Hallo zusammen, der Part tuts nun. War tatsächlich so, dass die Datei selbst falsch codiert war. Nun habe ich folge-Problem, was zaw nicht unbeding mit html zu tun hat, aber vielleicht hat auch jemand einen Tipp: Ich generiere pdfs mit tcpdf. Umlaute im Text sind alles oK. Nun hakt es aber bei den Dateinamen.

$docname_soll=Müller_300522.pdf
$docname_ist=Mller_300522.pdf

nutzte ich urlencode:

$docname_ist=Mc3bcller_300522.pdf
$pdf->Output($docname, 'I'); 

Irgendwer eine idee, wie ich Umlaute in Dateinamen umsetzen kann?

mfG tsunami

Edit Rolf B: Beitrag abgetrennt, Code formatiert

[Gunnar Bittersmann]

@@tsunami

der Part tuts nun. War tatsächlich so, dass die Datei selbst falsch codiert war.

Und dass das das HTML falsch war. Haste auch korrigiert?

Nun habe ich folge-Problem, was zaw nicht unbeding mit html zu tun hat, aber vielleicht hat auch jemand einen Tipp:

Ja: neues Problem → neuer Thread.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo tsunami,

da kommen verschiedene Aspekte zusammen.

• 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?

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.

Ich glaube, dass hier massive Systeminkompatibilitäten (Server-Betriebssystem, Server-Filesystem, Webserver-Software) lauern können.

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. Irgendwie errät er das. M%FCller.txt lässt er mir dabei in der Adresszeile stehen, und M%C3%BCller.txt setzt er in Müller.txt um (schickt den Request aber mit M%C3%BCller.txt an den Server).

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.

Rolf

[Der Martin]

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

[Gunnar Bittersmann]

@@Rolf B

Wenn der Browser das PDF abholen soll, muss das ü auf jeden Fall URL-codiert sein.

Nö, muss nicht. Die Umwandlung von IRI zu URI machen die Browser schon.

Ob es richtig ist, es UTF-8 zu codieren, ist aber eine andere Frage

Mit Betonung auf „eine“. Die zweite andere Frage ist die nach der Normalisierungsform.

Wenn ich eine lokal (auf macOS) erstellte Datei grüße.html per FTP mit FileZilla auf meinen Webserver schiebe, funktioniert die Verlinkung mit <a href="grüße.html"> nicht. Aber auch nicht prozent-escapet mit <a href="gr%C3%BC%C3%9Fe.html">.

Wenn ich dann aber die Datei auf dem Server mit FileZilla umbenenne in grüße.html (ja, richtig gelesen: ich verwende denselben Dateinamen wieder), dann funktioniert’s – beides.

Das liegt daran, dass ü zunächst decomposed vorlag, d.h. als u gefolgt von U+0301 COMBINING ACUTE ACCENT. Nach der Umbenennung ist es precomposed: U+00FC LATIN SMALL LETTER U WITH ACUTE.

Siehe Spielwiese, auf der ich 2 Dateien grüße.html nebeneinander habe – eine vor der Umbenennung (NFD), eine danach (NFC). Die Dateinamen werden zwar in FileZilla gleich angezeigt, sind aber verschieden, weshalb die Dateien nebeneinander im selben Verzeichnis existieren können.

BTW, die Normalisierung betrifft hier nur das ü, nicht das ß.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

ach ja, diese Geschichte gibt's ja auch noch.

Wer sich diese combining doodahs ausgedacht hat, hatte bestimmt gute Absichten. Womit man bekanntlich den Weg zur Hölle pflastert.

Unter Windows NTFS ist es genauso. Ich habe eine Datei "müller.txt" (precomposed) und eine Datei "mu¨ller.txt" (decomposed) erzeugt - per PowerShell von der Befehlszeile. Auf der Befehlszeile ("dir m*.txt") wurde die zweite Date decomposed angezeigt. Im Windows Explorer sahen beide wie "müller.txt" aus. Ich konnte beide mit Notepad öffnen, bearbeiten, speichern - Notepad zeigte mir beide Male "müller.txt" an und hielt die Dateien beim Bearbeiten auch korrekt auseinander.

Brrrr.

Rolf

[Der Martin]

Hallo Rolf,

Wer sich diese combining doodahs ausgedacht hat, hatte bestimmt gute Absichten.

die Absicht war vermutlich, weniger Codepoints zu brauchen - nämlich nur die combining diacritics und die jeweiligen Basiszeichen. Warum man das dann aber nicht durchgehalten und stattdessen doch wieder jedem diaktitischen Zeichen seinen eigenen Codepoint reserviert hat, ist mir auch nicht klar. Ent oder weder.

Und da diese Kombiniererei nicht auf jeder Plattform richtig funktioniert, meidet man sie besser.

Unter Windows NTFS ist es genauso. Ich habe eine Datei "müller.txt" (precomposed) und eine Datei "mu¨ller.txt" (decomposed) erzeugt - per PowerShell von der Befehlszeile. Auf der Befehlszeile ("dir m*.txt") wurde die zweite Date decomposed angezeigt. Im Windows Explorer sahen beide wie "müller.txt" aus. Ich konnte beide mit Notepad öffnen, bearbeiten, speichern - Notepad zeigte mir beide Male "müller.txt" an und hielt die Dateien beim Bearbeiten auch korrekt auseinander.

Dass der Explorer und andere Anwendungen die beiden Dateien auseinanderhalten, ist klar und korrekt. Schließlich sind es ja unterschiedliche Dateinamen (zumindest technisch, nicht semantisch). Dass der Explorer beide gleich anzeigt, ist eigentlich auch korrekt, wenn auch verwirrend.
Aber die Kommandozeile beherrscht das Kombinieren anscheinend nicht und zeigt die Namen daher unterschiedlich an. Nun ja ...

Brrrr.

Genau.

Einen schönen Tag noch
 Martin

[MudGuard]

Hi,

Wenn ich eine lokal (auf macOS) erstellte Datei grüße.html > Das liegt daran, dass ü zunächst decomposed vorlag, d.h. als u gefolgt von U+0301 COMBINING ACUTE ACCENT. Nach der Umbenennung ist es precomposed: U+00FC LATIN SMALL LETTER U WITH ACUTE.

Willst Du uns etwa ein ú für ein ü vormachen?

Das hätte doch vorher eher U+0308 COMBINING DIAERESIS und danach U+00FC LATIN SMALL LETTER U WITH DIAERESIS sein müssen.

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

Willst Du uns etwa ein ú für ein ü vormachen?

Das hätte doch vorher eher U+0308 COMBINING DIAERESIS und danach U+00FC LATIN SMALL LETTER U WITH DIAERESIS sein müssen.

Zu dumm zum Kopieren. 🤦‍♂️ Äh, Namen sind Schall und Rauch. 🤪

🖖 Живіть довго і процвітайте

[Raketenwilli]

Irgendwer eine idee, wie ich Umlaute in Dateinamen umsetzen kann?

Mal ganz grundsätzlich:

1. Geht es um die Dateinamen mit welchem das Dokument auf dem Server gespeichert werden soll oder um Dateinamen, welche dem USER-Agent (Browser, curl, wget & Co.) zum Speichern vorgeschlagen werden?

2. Falls es an irgendeiner Stelle um einen Rückgriff auf das Dateisystem des Servers geht würde ich dringend davon abraten, Ergebnisse von Tests auf einem Betriebssystem wie z.B. Windows (nehmen wir das leidige XAMPP) auf einen Produktivserver z.B. mit Linux oder BSD als OS zu übertragen. Beschreibe also Dein OS.

[tsunami]

Hallo zusammen, also das Problem ist zwischenzeitlich gelöst. In der Konfigdatei TCPdfconfig mussten zwei Zeilen auskommentiert werden.

Es ging um die Ausgabe. Also einfach die Erzeugung einer pdf-Datei mit Umlauten drin. Die Dokumentnamen werden dynamisch generiert. Name_Datum_Funktion.pdf Es soll halt zB Müller_300522_Kassierer.pdf rauskommen und der Müller machte Probleme. Wen es interessiert:

	if ($dest[0] != 'F') {
 			$name = preg_replace('/[\s]+/', '_', $name);
 			$name = preg_replace('/[^a-zA-Z0-9_\.-]/', '', $name);
	}

Edit Rolf B: Mehrzeilige Codebeispiele schließt man in ~~~ ein, und schreibt hinter das öffnende ~~~ die Programmiersprache. Hier also ~~~php.

mfG tsunami