Umlautprobleme allgemein- grundsaetzliche Erklaerungen?

  • Hi,



    diesmal habe ich mal ein Problem, bei dem ich mittlerweile garnichts mehr verstehe...


    Ich habe meine gesammelten Bilder auf einem Linux Rechner liegen. Schon seit Jahren. D.h. das ist gewachsene Struktur. So haben die Ordner zum Teil halt auch deutsche Umlaute (also /bilder/2001/März).


    Zum Teil wurden diese Verzeichnisse von einem Linux Client geschrieben, zum Teil ueber Samba (wobei dabei wiederum von verschiedenen Win Versionen, z.T. von englischsprachigen Versionen). zum Teil auch via Browser erstellt usw. Also echt multi-kulti!


    So sehen derzeit unter Linux die Verzeichnisse so aus:

    Zitat


    ./2010/Maerz
    ./2004/März
    ./2005/März
    ./2011/März

    Anderes Beispiel:


    Und noch ein merkwuerdiges Beispiel:

    Zitat

    [root@nas 2011]# mv März/ März
    [root@nas 2011]# ls
    Februar Januar M?rz
    [root@nas 2011]#




    Jetzt wuerde ich das ganze gerne ein wenig aufraeumen. Weiss aber ueberhaupt nicht wo anfangen. Ich weiss ja nichtmal, welche Zeichensaetze dieses Gewirr da oben enthaelt. Sowohl iconv als auch convmv wollen ja "from" Zeichensatzangaben. Und bei dem letzten Eintrag verweigern die meisten Programme sowieso ihre Zusammenarbeit- was ist das bloss?


    Kann mir jemand ein paar Tips geben, wie man das vernuenftig in den Griff bekommen kann?






    Danke!


    Christian

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    Einmal editiert, zuletzt von knebb ()

  • Tja - abhängig davon , wer da geschrieben hat ( Sys ) haste halt deren ASCII für den entsprechenden Umlautda stehen oder halt die "nicht-deutsche" Version


    Ich würde das Ganze per Script abhandeln .
    Um den ASCII dieses <Umlaut-Karo> zu erhalten , ein ls>[file]
    Denn ein simples suchen/ersetzen - in das Zeichen , was geht ;)


    HJS


    EDIT


    OH - der letzte Teil war nicht gefragt ... dumdidum ... :gap


    EDIT2


    Oder doch ?!? - etwas konfus heut :gap


    Grund für diese Erscheinung ist die Tatsache , daß die Umlaute Sonderzeichen sind , die in unterschiedlichen System unterschiedliche Codes haben .
    Einfachster Weg , daß Problem zu umgehen , ist keine Verwendung von Sonderzeichen - also generell ae ue oe .
    Alternative ist die Zeichensätze auf jedem System anzupassen, kann aber haarig werden ...

    Working VDR : VDR-1.4.6 - ACPI/NVRAM Wakeup - working on hjslfs

    Einmal editiert, zuletzt von hjs ()

  • Das ist doch irgendwie alles Mist.


    Selbst wenn ich aktuell Verzeichnisse erstelle, klappt das nicht.
    Siehe:

    Zitat

    [root@nas 2011]# mv März/ März


    [root@nas 2011]# ls


    Februar Januar M?rz


    Das passt unter Linux schon nicht zusammen. Und ein englisches Windows XP (via Samba) zeigt das dann als "M_rz" an. :wand


    Ist denn nicht der Vorteil von UTF-8, dass alle Zeichen auf allen Systemen sauber dargestellt werden? Warum klappt das hier nicht? Solange wie das Problem nicht geloest ist, brauche ich garnicht erst anfangen, die alten zu konvertieren- ist dann sowieso im falschen Format.


    Gruesse


    Christian

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

  • Mal ne bescheidene Frage :


    Gehste per autologin in in dein NAS ?


    Da hab ich auch schon mal wild geflucht , auf der Console mit autologin kamen die Umlaute irgendwie , auf der zweiten mit manuellem Login kamen se sauber .
    Auch : Tippeln ja , anzeigen nö - beim autologin ..


    HJS

  • Ach ja, nochmal was:


    Wenn ich unter Windows das M_rz umbenenne in März, erscheint es auf der Linux Konsole als März.


    Ich flippe noch aus....das ist doch alle Mist. Irgendwas ist da doch maechtig faul- ich weiss schon, warum meine Tastatur mittlerweise auf englischem Keyboard habe...


    Argl...direkt auf der Konsole ist es wieder März. Nur via PuTTY zeigt er März an....gibt's das denn?



    /KNEBB

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P


  • Ist denn nicht der Vorteil von UTF-8, dass alle Zeichen auf allen Systemen sauber dargestellt werden?


    Wenn das Dateisystem die Dateinamen in UTF-8 Speichert. Und wenn alle Programme dann damit umgehen können, ja dann ist das toll.


    Aber mal ehrlich, selbst mein total verhunztes Linux auf meinem VDR kann das
    ---
    easyVDR:~/test1233# mkdir März
    easyVDR:~/test1233# ls -l
    insgesamt 4
    drwxr-xr-x 2 root root 4096 2011-03-30 13:54 März
    easyVDR:~/test1233#
    ---


    Wenn DAS noch nicht mal auf deinem NAS geht dann ist da am System schon generell was faul. Dann kannst du Samba und Win erstmal außen vor lassen, erstmal sehen das dein Linux selber mit sich klar kommt.


    cu

  • Vergesst das mit den "NAS". Das ist eine reine CentOS5 Linux Kiste, die nur als Hostnamen NAS hat! Da habt Ihr wieder mehr angenommen als gesagt ;)


    Ok, habe zumindest mal ein Problem entlarvt: PuTTY stand NICHT auf UTF-8. Somit werden unter Windows erzeugte Umlaute jetzt auch sauber auf der Konsole angezeigt.


    Nur: Was mache ich jetzt mit den alten Dateien? In welchem Zeichensatz sind die geschrieben (damit das mit dem convmv sauber klappt)?


    /KNEBB

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

  • So,


    Zitat


    ./convmv -f iso-8859-15 -t utf-8 -r /srv/bilder/ --notest


    hat tatsaechlich alle "kruden" Zeichen in UTF-8 umbennant. Sehen unter Windows jetzt auch gut aus.


    Scheinbar war das die Loesung. Den "from" Zeichensatz habe ich einfach geraten....

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

  • Auch wenns jetzt zu spät ist ein allgemeiner Fehler ist nicht zwischen den verschiedenen Anwendungen zu unterscheiden. Also Samba, Putty , lokales Filesystem, locale Einstellungen. Wenn man da erstmal einen definierten Zustand in 2en erreicht (zB Erkenntnis der benutzten locale + richtig konfiguriertes Putty ergibt sich der Rest meistens. iso-8859-15 und iso-8859-1 sind IMHO weitestgehend deckungsgleich und der wahrscheinlichste Kandidat hierzulande.


    ä sowas deutet immer auf multibyte character (also UTF8) in einer nicht UTF8 Umgebung hin.


    Zitat

    Ist denn nicht der Vorteil von UTF-8, dass alle Zeichen auf allen Systemen sauber dargestellt werden?


    Alle Zeichen ja, alle Zeichensätze in jeder Kodierung nein (geht auch garnicht).

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Hmm....
    so alles scheint aber nicht sauber zu klappen.


    Aus dem oberen macht der das untere- via PuTTY eingeloggt als UTF-8. Wass'n da los?

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

  • Offensichtlich stimmen NICHT alle Zeichen überein .


    Schätze , du hast zwei Möglichkeiten :


    a) du ermittelst , welche Zeichen nicht passen und meidest die
    b) du ermittelst , welche Zeichen nicht passen und suchst den passenden Zeichsatz ODER editierst den am nächsten kommenden Vorhandenen


    HJS


  • 04-Knockin´ On Heaven´s Door.mp3


    Das >>´<< ist hier eh das falsche Zeichen (eigentlich gibts das ja nicht einzeln sondern ist ein http://de.wikipedia.org/wiki/Deadkey ), da gehört ein >>'<< hin (oder ganz korrekt ein >>’<<). Vermutlich greift hier noch ein anderer Mechanismus (Linux Konsole, Putty, Windows, <keine Ahnung>) rein der da versucht irgendwas clever umzusetzen.


    Oder das ist nich das "normale" >>´<< sondern irgendwas exotisches aus dem Unicodebereich was zufällig nur genauso aussieht aber nicht in jedem Zeichensatz ist.


    cu

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!