Frage zu Zeichensätzen bei Dateinamen

  • Hallo zusammen!


    Ich habe vor ein paar Tagen unsere Homepage zu einem anderen Provider verschoben.
    Alt: Webhostone; Neu: Netcup


    Jetzt habe ich gerade bemerkt, dass es anscheinend ein Problem mit den Umlauten in Dateinamen habe.
    Bemerkt habe ich es, weil mit Wordpress ein paar Bilder mit Umlauten im Namen nicht angezeigt hat plötzlich.
    Das wäre noch nicht schlimm, aber ich habe auch Nextcloud mit ein paar tausend Dokumenten dort hin kopiert.


    Es handelt sich um ein Webhosting-Paket, welches in einer chroot-Umgebung läuft.
    Damit kenne ich mich nicht so gut aus. Aber evtl. kann mir jemand anhand der Symptome sagen, was ich mal machen könnte.
    (außer Support kontaktieren, aber das war nicht sehr motivierend im ersten Kontakt heute :-(


    1) Es gibt in der Verwaltung der Domain einen web-basierten Dateimanager. Dieser zeigt mir ein ? statt des Umlauts an.
    2) Per SSH eingeloggt komme ich in eine bash-4.1: Die Namen werden mit ls dann da auch mit einem ? gelistet
    3) Will ich die Datei umbenennen und nutze die Tab-Taste zur Vervollständigung des Namens, dann erscheint statt des ? dort ein /344. (das ist der Zeichencode für das "ä" bei ISO-8859-15 Codierung.)
    4) Ich kann in SSH keinen Umlaut eintippen. Ich drücke "ä", und es passiert absolut gar nichts!
    4) Ich wollte den Zeichensatz des Systems prüfen. Aber echo $LANG ergibt nichts. Diese Variable ist nicht gesetzt.
    Was macht denn ein System, wenn gar keine Variable gesetzt ist? -- Und lässt sich das für eine einzelne chroot-Umgebung explizit setzen, oder geht das nur systemweit?
    5) lokal bei mir auf dem PC ist seit Jahren alles auf UTF-8 eingestellt unter Linux. Von dort habe ich die Dateien mit Filezilla auf den FTP von netcup kopiert.
    6) Wenn ich mir die Dateien in Filezilla anschaue, dann werden die Umlaute übrigens korrekt dargestellt.


    So, nun zu den Merkwürdigkeiten:
    1) Wenn ich eine Umlaut-Datei lokal anlege und mit dem Nextcloud-Client sichere, dann wird sie auf dem Server mit dem ? angezeigt.
    Wenn sie sich von da aus nach Windows verteilt auf meinen anderen PC, dann kommt sie auch wieder mit Umlaut an.
    ---> Ist es "nur" ein Problem mit der Darstellung der Umlaute in SSH und dem Web-Frontend? (beides nutze ich ja nicht)
    2) Wordpress zeigt aber die Bilder nicht an. Weshalb ich vermute, dass es schon ein echtes Problem sein könnte.



    Zu Hilfe bitte, ich bin etwas überfordert.
    Und bitte verschont mich mit Tipps, dass Umlaute nicht in Dateinamen rein gehören. Diesen Tipp auch schon vom Support erhalten. ;-)


    Vielen Dank.


    Gruß,
    Marcus

    Hardware: Zalman HD160XT; Asus H97M-Plus, 1024MB RAM, Digital Devices Cine S2 (rev 7), Atric-Einschalter, NEC3520 DVD-Laufwerk, Samsung 256 GB SSD-Festplatte --> darauf yaVDR 0.6
    Hifi: Denon AVR4306, Samsung UE40ES6300

  • 4) Ich wollte den Zeichensatz des Systems prüfen. Aber echo $LANG ergibt nichts. Diese Variable ist nicht gesetzt.

    Du kannst dir mit locale anzeigen lassen, was an Umgebungsvariablen für die Lokalisierung gesetzt ist:

    Code
    1. locale # zeigt die aktuellen Einstellungen für die locale-Variablen
    2. locale -a # listet die verfügbaren locales auf


    Was macht denn ein System, wenn gar keine Variable gesetzt ist?

    Ich denke dann fallen die Programme auf die Standard-Locale (z.B. C oder POSIX) zurück.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Dateien mit Umlauten im Namen zu erstellen schreit doch geradezu nach Problemen - eigene Selberschuld..




    Du logst dich also per ssh irgendwo auf dem Server ein, aber sagst nicht mit welchem client/system.
    Wenn du z.B. putty verwendest, musst du auch dort die Zeichenkodierung des entfernten Systems einstellen. Und die Umgebungsvariable kannst du in der ssh session auch setzen.

  • Hallo zusammen!


    @Seahawk86: der locale Befehl steht in der chroot-Umgebung nicht zur Verfügung. Daher weiß ich nicht, welche Spracheinstellung auf dem Server gesetzt ist, und seitens Netcup-Support wurde diese Frage bisher nicht beantwortet. Ich habe nur erfahren "dass der Server nichts verändert".



    wirbel : ich nutze lokal das Gnome-Terminal von Mageia Linux. Lokal ist UTF-8 eingestellt.
    Mal ne Frage, weil ich das nicht verstehe, was du meinst: Wo und wie genau werden die Dateinamen gespeichert auf dem Server? - Ist das abhängig von der $LANG Umgebungsvariablen, die ich auf dem Server setze? -- Sprich, wenn ich erst UTF einstelle und danach die Dateien kopiere, dann wären sie "anders" abgelegt als wenn ich die Dateien mit der Standardeinstellung kopiere?


    Welchen FTP-Client sollte ich denn verwenden? -- Ich habe unter Linux sowohl gftp als auch Filezilla installiert. Und ein Windows-System mit Filezilla hätte ich auch noch.




    Ich mag das nicht gerne akzeptieren, wenn wir in Deutschland auf Umlaute verzichten müssen.
    Für eine reine Web-Präsenz mag das ja ok sein, aber a) ist es im Jahr 2017 technisch möglich Umlaute abzuspeichern und b) ist mit Diensten wie Nextcloud ein replizieren ganzer Ordnerstrukuren möglich, wo ggf. sogar viele Benutzer gleichzeitig mit arbeiten. Ich denke, dass ein kompletter Verzicht auch Umlaute im täglichen Leben total unpraktisch ist.
    Anyways, ich verstehe wohl dass ich selbst Teil des Problems bin.



    Gruß,
    Marcus

    Hardware: Zalman HD160XT; Asus H97M-Plus, 1024MB RAM, Digital Devices Cine S2 (rev 7), Atric-Einschalter, NEC3520 DVD-Laufwerk, Samsung 256 GB SSD-Festplatte --> darauf yaVDR 0.6
    Hifi: Denon AVR4306, Samsung UE40ES6300

  • Gerade ist mir noch etwas aufgefallen.
    Ich hatte mir gestern eine .bashrc Datei angelegt, um mir Aliase und Umgebungsvariablen zu setzen.
    Wenn ich mich nun per SSH einlogge, dann wir diese Datei aber ignoriert. Ich muss sie explizit einlesen mit "source /.bashrc".
    Anscheinend klappt auch das nicht in der chroot-Umgebung. Schade.

    Hardware: Zalman HD160XT; Asus H97M-Plus, 1024MB RAM, Digital Devices Cine S2 (rev 7), Atric-Einschalter, NEC3520 DVD-Laufwerk, Samsung 256 GB SSD-Festplatte --> darauf yaVDR 0.6
    Hifi: Denon AVR4306, Samsung UE40ES6300

  • Bei remote logins (ssh, telnet, ...) wird .bash_profile statt .bashrc ausgeführt.

  • >> wirbel : ich nutze lokal das Gnome-Terminal von Mageia Linux. Lokal ist UTF-8 eingestellt.
    >> Mal ne Frage, weil ich das nicht verstehe, was du meinst: Wo und wie genau werden die
    >> Dateinamen gespeichert auf dem Server? - Ist das abhängig von der $LANG Umgebungsvariablen,
    >> die ich auf dem Server setze? -- Sprich, wenn ich erst UTF einstelle und danach die Dateien
    >> kopiere, dann wären sie "anders" abgelegt als wenn ich die Dateien mit der Standardeinstellung
    >> kopiere?


    Die Dateinamen sind byte Folgen, eine Anzahl von bytes, die von Programmen dargestellt/interpretiert werden.
    Einige Programme (viele..) respektieren Umgebungsvariablen (u.a.) zur Angabe der Zeichenkodierung. Jedem
    Zeichen werden entweder genau ein byte oder mehrere bytes zugeordnet (bis zu vier).



    Für alle Standard-Zeichen, sowas wie 'A'..'Z', 'a'..''z' oder '0'..'9' wird je Zeichen
    ganz genau nur ein byte verwendet, wobei nur die unteren 7bit des bytes verwendet werden.
    Und in jeder Zeichenkodierung werden diese Zeichen dann gleich angezeigt.


    Tippst du ein 'a' wird daraus dann genau ein byte 0x61 und jedes Programm stellt das wieder als 'a' dar.



    Tippst du dagegen auf einem Windows Programm, welches kein UTF8 kann ein Sonderzeichen 'ä',
    dann passiert folgendes:
    'ä' -> win@cp1252 -> byte 0xE4 <-> linux@utf8 -> <UNDEFINIERT>
    Die Zeichentabelle von UTF8 kennt keine byte folge 0xE4; die Anzeige ist beliebig (Fragezeichen, Ypsilon mit Punkten, whatever..).



    Gibts du auf einem utf8 System ein 'ä' und liest das auf einem Windows@CP1252 Programm zurück,
    ergibt das genauso Unsinn:
    'ä' -> linux@utf8 -> bytes 0xC3 0xA4 <-> windows@cp1252 -> 'Ã' '¤' (zwei Zeichen, ein A mit Tilde und eine 'Kartoffel'..))


    Nur, wenn die gleiche byte folge auf beiden Systemen gleich interpretiert wird, siehst du wieder das gleiche Zeichen:
    'ä' -> linux@utf8 -> bytes 0xC3 0xA4 <-> windows@utf8 -> 'ä'
    Alle Systeme müssen im Falle von Sonderzeichen also die gleiche Zeichentabelle benutzen.


    Wenn du das nicht garantieren kannst, solltest du um Sonderzeichen einen weiten Bogen machen.
    Und genau wegen der Probleme hat dir der Support den richtigen Tipp gegeben: Finger weg von SOnderzeichen in Dateinamen.
    Es sei denn, du weißt, was du tust.

  • Vielen Dank für die tolle Erklärung.
    Das bedeutet ja zum Glück zuerst mal, dass die Bytefolge nicht kaputt ist, sondern es alles "nur" eine Frage der Darstellung ist.


    Gruß,
    Marcus

    Hardware: Zalman HD160XT; Asus H97M-Plus, 1024MB RAM, Digital Devices Cine S2 (rev 7), Atric-Einschalter, NEC3520 DVD-Laufwerk, Samsung 256 GB SSD-Festplatte --> darauf yaVDR 0.6
    Hifi: Denon AVR4306, Samsung UE40ES6300

  • Es bedeutet auch, dass ein WIndows u.U. Dateien nicht anzeigt, die auf einem Linux gültige Dateinamen haben.