Umlaute im Dateipfad

[thobie]

Moin, Moin,

ich hatte bisher mixed content in meinem Foodblog https://www.nudelheissundhos.de.

Ich habe auf Anraten eines Kollegen mit dem Plugin Search & Replace die URL „http://www.nudelheissundhos.de“ durch „https://www.nudelheissundhos.de“ in der Datenbank ersetzt. Dieses Problem entstand anscheinend dadurch, dass das Foodblog vor 10 Jahren die ersten Jahre ohne SSL-Zertifikat betrieben wurde. Diese Aktion vorher in Testumgebung lokal getestet. Erfolgreich. Dann im Live-Blog ersetzt. Ebenfalls erfolgreich. Front-/Backend funktioniert. 127 Tabellen mit etwa 100.000 Zellen wurden aktualisiert.

Jetzt habe ich noch folgendes Schönheitsproblem: Die Fotos werden in Beiträgen nicht angezeigt, wenn sie Umlaute im Dateinamen haben. Döner, Gemüse, Geflügel usw. Die URL des jeweiligen Fotos ist korrekt, nur kann sie der Browser anscheinend nicht interpretieren, er baut Sonderzeichen anstelle der Umlaute ein. Kopiere ich nur die URL eines Fotos in ein Browserfenster, wird es korrekt angezeigt.

Wie behebe ich das?

Grüße aus Hamburg

Thobie

 

[JARVIS1187]

Dateinamen sollten niemals Umlaute/Sonderzeichen haben. Benenn die Dateien um und ändere die Verweise dann entsprechend.

 

[oneOeight]

Die URL des jeweiligen Fotos ist korrekt, nur kann sie der Browser anscheinend nicht interpretieren, er baut Sonderzeichen anstelle der Umlaute ein. Kopiere ich nur die URL eines Fotos in ein Browserfenster, wird es korrekt angezeigt.

Was heißt Sonderzeichen?
% irgendwas?
Das ist normale URL Kodierung.
Das Problem ist ähnlich der Zeichenkodierung der DB, das du hattest.
Ist das Forum PHP? Das hat doch auch Funktionen dafür.

 

[Cherusker]

Ich habe auf Anraten eines Kollegen mit dem Plugin Search & Replace die URL „http://www.nudelheissundhos.de“ durch „https://www.nudelheissundhos.de“ in der Datenbank ersetzt.

Damit hat Dein Umlautproblem nicht zu tun.

Diese Aktion vorher in Testumgebung lokal getestet. Erfolgreich. Dann im Live-Blog ersetzt. Ebenfalls erfolgreich. Front-/Backend funktioniert. 127 Tabellen mit etwa 100.000 Zellen wurden aktualisiert.

Jetzt habe ich noch folgendes Schönheitsproblem: Die Fotos werden in Beiträgen nicht angezeigt, wenn sie Umlaute im Dateinamen haben. Döner, Gemüse, Geflügel usw. Die URL des jeweiligen Fotos ist korrekt, nur kann sie der Browser anscheinend nicht interpretieren, er baut Sonderzeichen anstelle der Umlaute ein.

Das nennt sich URL Encoding. Früher kannten Computer gar keine Umlaute, heute können sie sogar fremde Alphabete anzeigen (kyrillisch, arabisch, japanisch etc.) Im Internet ist aber einiges immer noch auf reines ASCII-128 beschränkt.

Dateinamen werden daher von vielen Web-Anwendungen (wie Wordpress) "url-encodiert" ein ü wird dann zu %C3%BC. Dein Döner.jpg erscheint als D%C3%BCner.jpg. Das ist normal und gewollt, um möglichst wenig Probleme zu bekommen. Es ist aber sogar inzwischen möglich, Umlaute nach der Domäne unkodiert zu lassen. Dann muss alles (Web-Server-Kongiguration., Datenbank-, Tabellen- und Verbindungs-Collation, auf UTF-8 eingestellt werden (Wozu im allgemeinen auch geraten wird).

Die Domäne selbst kann auch Umlaute enthalten, die wird aber anders und ziemlich krank kodiert. Von Umlaut-Domänen solltest Du Abstand nehmen.

 

[thobie]

Ich habe vermutet, dass das mit dem entsprechenden Encoding zusammenhängt. Wie bringe ich denn dem Browser bei, dass er die Dateinamen mit Umlauten korrekt interpretiert und die Fotos in den jeweiligen Beitrag lädt?

Die Dateinamen liegen mit Umlaut im wp-content-Ordner. Der Blogbeitrag lädt sie nicht, zeigt einen grauen Hintergrund. Gehe ich mit der Maus darüber, zeigt er mir den Dateinamen mit (!) Umlaut. Kopiere ich diesen in ein neues Browserfenster, wird das entsprechende Foto korrekt geladen. Nur die Anzeige im Beitrag selbst klappt nicht.

 

[thobie]

Nachtrag: Ich hatte ja das Suchen/Ersetzen in der lokalen Testumgebung getestet. Dann die ersten Beiträge im Blog mit den fehlenden Fotos in der Testumgebung geprüft. Die Fotos wurden nun alle angezeigt, und zwar auch die Fotos mit einem Umlaut im Dateinamen, die nun im Live-Blog aber nicht angezeigt werden.

 

[Cherusker]

Dafür gibt es den php-Befehl urlencode()

Damit musst Du alle Ausgaben bearbeiten, die Nicht-ASCII-Zeichen enthalten können. Werden reine ASCII-Zeichen durch diese Funktion gejagt, wird nichts verändert.

Beispiel:
Aus Döner.jpg wird D%C3%B6ner.jpg
Aber Doener.jpg bleibt Doener.jpg

Ich kenne Wordpress zu wenig. Das letzte mal habe ich damit vor etwa 10 Jahren beschäftigt, aber dafür gibt es bestimmt eine fertige Option, das zu aktivieren.

Willst Du die URL mit Umlaut anzeigen, musst Du alle Systemteile auf UTF-8 einstellen. Dafür kann ich Dir kein Kochrezept geben. Das kann umfangreicher werden, bis hin zur Umkodierung von Datenbankinhalten.

 

[thobie]

Es liegt nicht am Browser. Denn dieser kann den in ein Browserfenster kopierten Dateinamen darstellen: https://www.nudelheissundhos.de/wp-content/uploads/2012/06/Hühnerbrühe_Teller.jpg. Nur WordPress kann dieses Foto mit diesem Dateinamen nicht im Blogbeitrag anzeigen, sondern zeigt einen grauen Hintergrund.

Und händisch die Dateinamen der Fotos mit einem Umlaut/Sonderzeichen zu ändern, ist nicht realisierbar. Denn WordPress legt ja beim Import eines Fotos dieses gleichzeitig in unterschiedlichen Größen z.B. für die Voransicht in der Mediathek usw. an. Damit hat dann jedes Foto mit Umlaut/Sonderzeichen nochmals 10 weitere "Duplikate", die geändert werden müssten.

 

[Cherusker]

Es liegt nicht am Browser. Denn dieser kann den in ein Browserfenster kopierten Dateinamen darstellen: https://www.nudelheissundhos.de/wp-content/uploads/2012/06/Hühnerbrühe_Teller.jpg. Nur WordPress kann dieses Foto mit diesem Dateinamen nicht im Blogbeitrag anzeigen, sondern zeigt einen grauen Hintergrund.

Ich habe nicht geschrieben, dass es am Browser liegt. urlencode musst Du in Wordpress verwenden.

Und händisch die Dateinamen der Fotos mit einem Umlaut/Sonderzeichen zu ändern, ist nicht realisierbar. Denn WordPress legt ja beim Import eines Fotos dieses gleichzeitig in unterschiedlichen Größen z.B. für die Voransicht in der Mediathek usw. an. Damit hat dann jedes Foto mit Umlaut/Sonderzeichen nochmals 10 weitere "Duplikate", die geändert werden müssten.

Eben! Deshalb verwende urlencode().

 

[thobie]

Ich habe das jetzt einmal in einem betroffenen Beitrag vom Mai 20212 geprüft. Das Foto mit Umlaut im Dateinamen wird im Beitrag nicht angezeigt.

Im Quelltext des Beitrags steht das Foto mit dem folgenden Code:

<img class="size-full wp-image-290" title="Hühnerbrühe_Bräter" src="https://www.nudelheissundhos.de/wp-content/uploads/2012/06/Hühnerbrühe_Bräter.jpg" alt="" width="505" height="531" />

Mit genau diesem Dateinamen befindet sich das Foto auch in dem genau so genannten Ordner auf dem Webspace des Blogs.

Will ich das Foto nachträglich nochmals in den Beitrag einladen, wird es mir in der Mediathek leer angezeigt, ich kann es somit nicht in den Beitrag einfügen.

Aber die URL des Fotos und auch die URL als Link zur Mediendatei in der Mediathek ist genau die gleiche wie im Quellcode: https://www.nudelheissundhos.de/wp-content/uploads/2012/06/Hühnerbrühe_Bräter.jpg.

Und wie erwähnt, kann ich auch mit diesem Dateipfad das Foto in einem leeren Browserfenster anzeigen lassen.

Ich habe jetzt bei noch folgenden Test gemacht: Fotodatei vom Webspace heruntergeladen. Aktuell in die Mediathek eingeladen. Von dort in den alten Beitrag importiert. Und siehe da, dies funktionierte. Allerdings hat die Datei mit den Umlauten beim jetzigen (!) Import in die Mediathek und in den Quellcode des Beitrags den folgende Dateinamen: https://www.nudelheissundhos.de/wp-content/uploads/2022/02/Huehnerbruehe_Braeter-1.jpg.

 

[thobie]

Ich beende diesen Thread jetzt einmal. Ich habe die Dateien auf dem Webspace geprüft. Ich muss anscheinend nach Gründung meines Foodblogs sehr schnell gemerkt haben, dass ich mir damit selbst Probleme erzeuge, wenn ich Dateinamen mit Umlauten verwende. Denn es befinden sich nur in vier Ordnern von 2012, also von 05–08/2012, Dateinamen mit Umlauten. Ab 09/2012 habe ich das anscheinend begriffen und abgestellt. Nach 09/2012 finde ich nur noch ausgeschriebene Umlaute wie ae, oe und ue.

Ich habe jetzt diese wenigen Dateinamen in den Ordnern 05–09/2012, es dürfte sich um vielleicht 30–40 Fotos gehandelt haben, auf dem Webspace händisch geändert und jeweils die Umlaute ersetzt.

Die wenigen Blogbeiträge in diesen vier Monaten bearbeite ich händisch.

Problem gelöst. Danke für Eure Hilfe!

 

[Cherusker]

Mit genau diesem Dateinamen befindet sich das Foto auch in dem genau so genannten Ordner auf dem Webspace des Blogs.

Genau das bezweifel ich.
Sowohl https://www.nudelheissundhos.de/wp-content/uploads/2012/06/Hühnerbrühe_Bräter.jpg wir auch
https://www.nudelheissundhos.de/wp-content/uploads/2012/06/Hühnerbrühe_Bräter.jpg werfen einen 404er

Ich war zu spät.

 

[JARVIS1187]

All dieses Hin und Her, obwohl ich genau das geraten hatte - im ersten Kommentar.
Heute Nacht war genau das angeblich noch nicht realisierbar.

Und händisch die Dateinamen der Fotos mit einem Umlaut/Sonderzeichen zu ändern, ist nicht realisierbar. Denn WordPress legt ja beim Import eines Fotos dieses gleichzeitig in unterschiedlichen Größen z.B. für die Voransicht in der Mediathek usw. an. Damit hat dann jedes Foto mit Umlaut/Sonderzeichen nochmals 10 weitere "Duplikate", die geändert werden müssten.

Weißt du eigentlich selbst, was du schreibst? Ich habe echt das Gefühl (und das meine ich nicht böse und möchte dich nicht angreifen), dass du keine Ahnung davon hast, was du da auf technischer Ebene tust.

 

[thobie]

@JARVIS1187 Was soll die Kritik? Ich hatte bisher noch nicht geprüft, wie lange ich Dateinamen mit Umlauten abgespeichert hatte. Da das Foodblog seit 10 Jahren besteht, bin ich davon ausgegangen, dass es sich um viele Monate und eventuell Jahre handelt. Und das wäre –> händisch nicht realisierbar gewesen. Punkt. Dass es sich nur um vier Monate und etwa 30–40 Fotos handelte, habe ich erst vorhin festgestellt!

 

[fa66]

Was soll die Kritik? Ich hatte bisher noch nicht geprüft, wie lange ich Dateinamen mit Umlauten abgespeichert hatte.

JARVIS1187 möchte möglicherweise darauf hinaus, dass deine Kenntnisse über die – ich formuliere es einmal vorsichtig – »Gepflogenheiten« bei der Dateibenennung im bzw. für das WWW nicht weit gediehen sind. Leider machen es die modernen Redaktionssysteme leicht, zu glauben, sich nicht mehr damit beschäftigen zu müssen.

Alle Methoden, um die ASCII-Zeichen-Grenze herumzukommen, sind Übersetzungsfunktionen, die auf Server-Ebene untaugliche Bezeichnungen ändern oder maskieren – wenn sie denn aktiviert sind. Vielleicht sind dir in URIs bereits Dateinamen wie Hhnerbrhe_Brter, Huhnerbruhe_Brater oder solche mit den schon genannten %-Escapes aufgefallen.

Hier noch eine solche Benennungsrahmenbedingung, die formal bis heute im WWW besteht: Maximale Dateinamenlänge: 31 Zeichen – einschließlich Punkt und Dateinamenerweiterung.
Sehr alte Systeme und Browser würden längere Dateinamen, wie es sie heutzutage tatsächlich gibt, nicht auflösen. 31 Zeichen? Da sollte aber beim Mac-Nutzer was klingeln. Ja, die alte maximale MacOS-Dateinamenslänge – die sich Tim Berners-Lee bei der Erfindung des Internetdienstes World Wide Web zum Maß genommen hat. Das Web ist halt auf dem Mac erfunden worden.

 

[Cherusker]

Das Web ist halt auf dem Mac erfunden worden.

Nicht ganz! Das Web wurde auf NeXTStep entwickelt. NeXTStep wurde später von Apple gekauft und bildete ein entscheidendes Element des neuen Mac OS X und seinen Nachfolgern. Somit hat Mac OS X natürlich auch das Korsett (darunter die Länge von Dateinamen) übernommen.

Da Steve Job NeXTStep gegründet hatte, nachdem er bei Apple gefeuert wurde, kam er so zu Apple zurück und übernahm erneut das Ruder dort. Insofern besteht eine Beziehung zu NeXTStep, aber zur Zeit als Tim Berners-Lee begann das WWW zu entwickeln und sich dazu für ein Entwicklungssystem entscheiden musste, war der Aufkauf durch Apple noch nicht absehbar.

Dass man vieles mit so engen Grenzen entwickelt hat, ist vor allem im damals teuren Speicher begründet. Speicherbausteine mit so hohen Speicherapazitäten wie heute konnte man auch noch gar nicht entwickeln. Oder die Geräte nahmen die Größe von Schrankwänden ein, röhrten wie ein Düsenjet und saugten Strom ohne Ende.

Hier kann man die erste Website sogar noch aufrufen.

 

[fa66]

Nicht ganz! Das Web wurde auf NeXTStep entwickelt. NeXTStep wurde später von Apple gekauft und bildete ein entscheidendes Element des neuen Mac OS X und seinen Nachfolgern. Somit hat Mac OS X natürlich auch das Korsett (darunter die Länge von Dateinamen) übernommen.

Ersteres werde ich nicht in Abrede stellen; erwartbar ist, dass TBL auf beiden Systemen gearbeitet hat.

Letzteres (ab dem »Somit«), das eine Folge unterstellt, aber schon: Denn die 31-Zeichen-Grenze bestand bei MacOS m.W. seit 1984. Was bei den 8.3-Dateinamen eines MS-DOS für den Heimanwender gewaltig lang war.

MacOSX hatte wegen seines NeXT- und BSD-Unterbaus wiederum nie diese 31er-Grenze; im nahtlosen Classic-Modus wurden Dateinamen länger als 31 Zeichen auf 27 Zeichen plus eine 4 Zeichen lange sedezimale Erweiterung zur Anzeige unter MacOS-9.22 heruntergebrochen.

 

[ruerueka]

<klugscheiss>NeXTStep hatte doch UFS als Filesystem. Da war die max. Dateinamenslänge doch immer schon 255 bytes, oder? </klugscheiss>