PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Welcher Zeichensatz ist dies: "für März"



aus Hamburg
20.01.08, 19:49
Moin zusammen,

nach einigen Partitionsproblemen habe die Dateinamen leider keine Umlaute mehr.

Für März sieht nun so aus für März

Wie finde ich raus welcher Zeichensatz das ist, um dann z.B. mit Krename alle Dateien umbennen zu können?

Vielen Dank und Gruß aus Hamburg

m.o.o.
20.01.08, 20:16
Eventuell mit file.

gadget
20.01.08, 20:21
Das ist ein Kodierungsproblem. FAT32 z. B. wird IMO standardmäßig ohne UTF-8-Unterstützung eingebunden.

gadget
20.01.08, 20:23
Zum Umstellen von ISO auf UTF8 ist convmv dein Freund. Z. B.:
Testlauf:

convmv -f iso-8859-1 -t utf8 -r -i *
real:

convmv -f iso-8859-1 -t utf8 -r -i --notest *


Gruß,
gadget

aus Hamburg
20.01.08, 20:41
Danke für die schnellen Antworten, allerdings

kennt Krename keinen Zeichensatz "file" oder habe ich m.o.o. falsch verstanden?

ISO, weder iso-8859-1 noch eine der weiteren iso-8859-... -16, erzielt ein vernünftiges Ergebnis.

Weiter Tipps?

Gruß aus HH

m.o.o.
20.01.08, 21:34
file ist ein Programm ;)

Um welche Art von Dateien handelt es sich denn? Versuche mal "file <dateiname>" auf einem Terminal auszuführen.

gadget
21.01.08, 07:37
ISO, weder iso-8859-1 noch eine der weiteren iso-8859-... -16, erzielt ein vernünftiges Ergebnis.Was ist vernünftig? Vernünftig wäre z. B., die Ausgaben zu posten. Insbesondere mal die betroffene Datei mit file aufzurufen:

file DATEI

comrad
21.01.08, 10:48
Ein Encoding kann man nicht auslesen, denn es ist immer eine Interpretationssache...

Alex_K
21.01.08, 13:06
Für März sieht nun so aus für März


Für mich sieht das aus als würde sich bereits um UTF8 Datei-Namen Handeln, welche aber aber als ISO-8859* interpretiert werden.

Wie gadget schon schrieb, ist es vielleicht nur ein Problem mit dem entsprechenden Eintrag in der fstab.
Welche Paritionsprobleme hattest du?
Auf welchem Dateinsystem liegen deine Daten?
Wie bindest du diese Partition ein?

gadget
21.01.08, 15:15
Ein Encoding kann man nicht auslesen, denn es ist immer eine Interpretationssache...
Nur zum Verständnis: Wie interpretiere ich dann die Informationen über Textdateien?

file test.txt
test.txt: UTF-8 Unicode text, with very long lines
Wobei da ja noch nichts über die Kodierung im Filesystem gesagt ist ...

ThorstenHirsch
21.01.08, 18:59
Nur zum Verständnis: Wie interpretiere ich dann die Informationen über Textdateien?
Du wählst ein beliebiges Encoding aus, z.B. ISO8859-1 und probierst es erstmal damit. Wenn dann sowas dabei rauskommt...

¤
...kannst Du davon ausgehen, dass es das falsche Encoding ist. Außerdem weißt du vielleicht, dass in UTF8 die deutschen Sonderzeichen in 2 Byte kodiert sind. Wenn du also in einem Zeichensatz, bei dem jedes Zeichen als 1 Byte dargestellt ist (wie ISO8859-1) häufig 2 unlesbare Zeichen nebeneinander siehst und das erste auch noch dieses große A mit Schweif drüber ist (Ã), dann kannst du davon ausgehen, dass du dir gerade UTF8 anschaust, denn in UTF8 werden alle deutschen Umlaute mit dem gleichen Zeichen eingeleitet: Ã (in ISO8859-1 interpretiert; hexadezimal: c3).

gadget
21.01.08, 19:16
@ThorstenHirsch: Das ist mir alles klar ;)
Meine Frage bezog sich eher auf den Post von comrad bezüglich der Aussagekraft der file-Ausgabe.
Aber gerade dünkt es mich, dass ich der Begriffsverwirrung auf den Leim gegangen bin...

aus Hamburg
21.01.08, 20:58
Danke für die vielen Antworten, aber nun bin ich ein wenig verwirrt.

Vielleicht noch mal zu meiner Situation. Ich habe vor etwas längerer Zeit aus Versehen bei der Installation von opensuse 10.3 meine alte home-Partition (ext3) überschrieben. Sämtliche Daten konnte ich allerdings mit Testdisk (http://www.cgsecurity.org/wiki/TestDisk_DE) wieder herstellen und in meiner derzeitigen home-Partition (ext3) ablegen. Das einzige was dabei verändert wurde sind sämtliche Dateinamen, bei denen Umlaute oder ß vorkam. Wenn ich nun neue Daten anlege, ist es kein Problem Umlaute o.ä. zu benutzten.

file liefert bei einer Beispieldatei Folgendes, aber ich glaube nicht, dass das weiter hilft.?

file 2005_März_bis_April.doc
2005_März_bis_April.doc: Microsoft Installer

bei einer neu erstellten Textdatei:

file 2005_März_bis_April.txt
2005_März_bis_April.txt: ASCII text

Kann es sein, dass die einfachste Lösung für mein Problem ist, einfach die paar möglichen Umlaute bzw. deren entsprechenden Zeichen in Krename anzugeben und entsprechend zu ersetzen?

Gruß aus HH

gadget
22.01.08, 07:40
Poste doch mal deine /etc/fstab und die Ausgaben, die convmv im Testlauf für eine betroffene Datei liefert. Die Aussagen aus deinem Post #5 helfen halt nicht wirklich weiter ...

Alex_K
22.01.08, 13:24
Sämtliche Daten konnte ich allerdings mit Testdisk (http://www.cgsecurity.org/wiki/TestDisk_DE) wieder herstellen und in meiner derzeitigen home-Partition (ext3) ablegen. Das einzige was dabei verändert wurde sind sämtliche Dateinamen, bei denen Umlaute oder ß vorkam. Wenn ich nun neue Daten anlege, ist es kein Problem Umlaute o.ä. zu benutzten.


In dem Fall sieht es für mich so aus als ob TestDisk das Encoding falsch interpretiert hat, und deine bereits UTF-8 encodeten Daten nochmals mit UTF-8 encodet hat, also du hast jetzt doppelt UTF-8 encodetet Dateinamen.

Der entsprechenden Abschnitt aus convmv:


How to undo double UTF-8 (or other) encoded filenames

Sometimes it might happen that you "double-encoded" certain filenames,
for example the file names already were UTF-8 encoded and you acci‐
dently did another conversion from some charset to UTF-8. You can sim‐
ply undo that by converting that the other way round. The from-charset
has to be UTF-8 and the to-charset has to be the from-charset you pre‐
viously accidently used. You should check to get the correct results by
doing the conversion without "--notest" before, also the "--qfrom"
option might be helpful, because the double utf-8 file names might
screw up your terminal if they are being printed - they often contain
control sequences which do funny things with your terminal window. If
you are not sure about the charset which was accidently converted from,
using "--qfrom" is a good way to fiddle out the required encoding with‐
out destroying the file names finally


Ich würde es mal so testen:


convmv -f utf8 -t iso-8859-1 -r -i *


bzw. entsprechendes mit krename (was ich nicht kenne und deshalb keine weiteren Details geben kann).