Re: Falsch kodierte Datei suchen
Helga Fischer
Hallo Liste,
k3b verweigert mit das Brennen meiner Daten zwecks Sicherung.
Schuld daran ist 'o� L�ung.html' (mittels C&P hier mal eingefügt), nur habe ich überhaupt keine Ahnung, wie ich nun herausfinden soll, wo der Störenfried sich versteckt. k3b ist so nett und verrät es mir nicht.
Find will auch nicht, auch nicht, wenn man ihm den Suchbegriff per C&P in den Rachen wirft. Was tue ich denn jetzt, ich habe nämlich nicht die geringste Ahnung, welche Datei das sein könnte und es wäre mir auch reichlich gleichgültig, ob sie nun in einem lesbaren Zustand auf der CD landet oder nicht. Hauptsache, der Rest ist lesbar, falls ich ihn benötige.
Mein System hat halt nun mal Daten mit Codierungen aus allen meinen Linuxepochen drauf. Und irgendeinen schönen sauberen und gründlichen Konvertiermechanismus gab's ja nie.
Ein bißchen was konnte ich mit mvconv umkodieren, will das aber nicht blind auf alles loslassen. Kurisoserweise hat k3b auch von einigen Dateien, die ihm nicht geschmeckt haben, verraten, wo sie lagen.
Helga
Hallo, Helga, das hatten wir gerade vor ein paar Tagen. Ich habe diese Probleme gehabt und habe sie tw. immer noch. In k3b kannst Du Dir die Fehleranalyse ausgeben lassen und da steht dann die Datei drin. Ich habe mit Erfolg mit dem Konqueror mit C+P danach gesucht und es klappte bei den meisten. Dann habe ich das auch noch einmal unter Windows, wo die Dateien herkamen gemacht, und damit fast alle gefunden. Ein Tipp aus der Liste war: krename Von den KDE-Leuten erhielt ich die Meldung, dass das kein Bug in k3b sei, sondern meine Schuld, wenn .... Ein weiterer Tipp: Ja, der Umstieg auf utf8 ist sowieso nicht mehr zu verhindern ;);) In etwa so: man convmv Beispiel: convmv -f cp850 -t utf8 -r ./* --notest --lowmem Rueckgaengig: convmv -t cp850 -f utf8 -r ./* --notest --lowmem cp850 kann es sein, muss aber nicht, cp437 wäre auch möglich convmv --list sagt Dir was es so an encodings gibt. Ebenso: In der fstab steht beispielsweise: /dev/hda1 /windows/C ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0 Der Wert hinter der Option nls (hier utf8) sagt dem Rechner, welchen Zeichensatz er für die Dateinamen verwenden soll. Hier müsstest du einen Zeichensatz wählen, der mit dem deines Windows-Systems verträglicher ist. Ich meine, dass iso-8859-1 gehen würde. Die genaue Schreibweise kann ich dir gerade nicht sagen, da müsstest du mal die Dokumentation wälzen. Habe nur jetzt keine Zeit, wenn ich noch mehr finde, kann ichs ja mailen. Bin an einer Lösung des Problems interessiert, weil es noch nicht ganz geht (habe über 9000 Dateien), ggf. PM! Gruß Bernd ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
Hallo, Am Sun, 08 Jan 2006, Bernd Kloss schrieb: [..]
In der fstab steht beispielsweise: /dev/hda1 /windows/C ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0
Der Wert hinter der Option nls (hier utf8) sagt dem Rechner, welchen Zeichensatz er für die Dateinamen verwenden soll. Hier müsstest du einen Zeichensatz wählen, der mit dem deines Windows-Systems verträglicher ist. Ich meine, dass iso-8859-1 gehen würde.
Nein. Windows verwendet eine eigene Abart, zumindest unter vfat. Die heisst 'cp1250'. Bzw. cp850 unter einem deutschen DOS und cp437 unter englischem DOS. Jedenfalls: latin1 (ISO-8859-1) kann garantiert nicht alle Zeichen des Windowszeichensatzes darstellen, denn Windows verwendet mindestens die cp1250 Obermenge von latin1 -- oder auch andere Zeichensaetze (z.B. cp1252). Man lese aber bitte selber die Doku: ==== /usr/src/linux/Documentation/filesystems/ntfs.txt ==== Supported mount options ======================= iocharset=name Deprecated option. Still supported but please use nls=name in the future. See description for nls=name. nls=name Character set to use when returning file names. Unlike VFAT, NTFS suppresses names that contain unconvertible characters. Note that most character sets contain insufficient characters to represent all possible Unicode characters that can exist on NTFS. To be sure you are not missing any files, you are advised to use nls=utf8 which is capable of representing all Unicode characters. ==== Noch Fragen? -dnh -- Nur so aus Interesse: Bist Du in die Gesellschaft "Rettet das Semikolon!" eingetreten? ;-) [Jan Trippler in suse-linux über ein Script von David Haller]
Hallo Bernd, Am Sonntag 8 Januar 2006 00:38 schrieb Bernd Kloss:
Helga Fischer
schrieb am 08.01.06 00:16:02: k3b verweigert mit das Brennen meiner Daten zwecks Sicherung.
Schuld daran ist 'o� L�ung.html' (mittels C&P hier mal eingefügt), nur habe ich überhaupt keine Ahnung, wie ich nun herausfinden soll, wo der Störenfried sich versteckt. k3b ist so nett und verrät es mir nicht.
[...]
In k3b kannst Du Dir die Fehleranalyse ausgeben lassen und da steht dann die Datei drin.
Die Datei schon, aber nicht der Pfad :((
Ich habe mit Erfolg mit dem Konqueror mit C+P danach gesucht und es klappte bei den meisten.
Das hat auch nicht wollen. Dafür konnte ich über Konqui umbenennen, was ich auf der Shell nicht hingekriegt hatte.
Dann habe ich das auch noch einmal unter Windows, wo die Dateien herkamen gemacht, und damit fast alle gefunden.
Ich habe nur Linuxdaten, ein paar dürften noch aus meinen Susi-6.4-Zeiten stammen, obwohl eigentlich ausgemistet sein sollte. Die Daten, die sich hier quer legen sind mit großer Wahrscheinlichkeit iso8859-15, aber eine Gewähr habe ich nicht dafür.
Ein Tipp aus der Liste war: krename Von den KDE-Leuten erhielt ich die Meldung, dass das kein Bug in k3b sei, sondern meine Schuld, wenn ....
So klar war mir das nicht, warum k3b hier nicht mag. Vielleicht, weil es dann das iso-filesystem nicht sauber rüberbringt. Find' ich aber irgendwie übertrieben, wenn ich die Datei finden würde, könnte ich sie sicher auf öffnen oder umkodieren. Warum diese Datei dann nicht auf eine CD wandern kann, erschließt sich mir nicht.
Ein weiterer Tipp:
Ja, der Umstieg auf utf8 ist sowieso nicht mehr zu verhindern ;);) In etwa so: man convmv
Es gibt einen sdb-Artikel dazu, aber ich mochte der Harke nicht vertrauen, die alles umgräbt. Einzelne Dateien oder auch überschaubare Verzeichnisse - OK. Aber sonst?
Beispiel: convmv -f cp850 -t utf8 -r ./* --notest --lowmem Rueckgaengig: convmv -t cp850 -f utf8 -r ./* --notest --lowmem
Danke, wie gesagt, meine Datenbestände sind nicht von Windows erstellt, ich hatte als Arbeitssystem immer nur Linuxe in Gebrauch.
cp850 kann es sein, muss aber nicht, cp437 wäre auch möglich
Raten will ich jetzt nicht. [...]
Bin an einer Lösung des Problems interessiert, weil es noch nicht ganz geht (habe über 9000 Dateien), ggf. PM!
Ich habe eine ähnliche Frage schon mal gestellt. Wenn mich mein Gedächtnis nicht trügt, hat mir damals jemand einen Tipp für ein Perl-Skript gegeben, das in der Lage ist, die Codierung auszulesen. Dann kann man zielgerichtet umwandeln. Vielleicht guckst Du mal nach meinem Namen. So viel schreibe ich ja hier im Moment nicht. Helga -- ## OpenSource-Werkstatt in Reutlingen -- http://www.eschkitai.de/ ## Etikette - Nein Danke? -- http://www.suse-etikette.de.vu/ ## Wer hilft? -- http://hsqldb.sourceforge.net/web/openoffice.html
Am Sonntag, 8. Januar 2006 11:43 schrieb Helga Fischer:
(...). Ich habe nur Linuxdaten, ein paar dürften noch aus meinen Susi-6.4-Zeiten stammen, obwohl eigentlich ausgemistet sein sollte. Die Daten, die sich hier quer legen sind mit großer Wahrscheinlichkeit iso8859-15, aber eine Gewähr habe ich nicht dafür.
Dafür gibt es ja den interactive- und/oder test-Modus von convmv.
(...). Ich habe eine ähnliche Frage schon mal gestellt. Wenn mich mein Gedächtnis nicht trügt, hat mir damals jemand einen Tipp für ein Perl-Skript gegeben, das in der Lage ist, die Codierung auszulesen. Dann kann man zielgerichtet umwandeln. Vielleicht guckst Du mal nach meinem Namen. So viel schreibe ich ja hier im Moment nicht.
Ich hab in einer Antwort mal eine URL zu einem Perl-Einzeiler angegeben: http://www.cl.cam.ac.uk/~mgk25/unicode.html#perl Der erkennt, ob in den ihm übergebenen Daten im UTF8-Sinne ungültige Zeichen sind. Die Daten können Dateien sein (dann gibt der Einzeler auch die Dateinamen aus, welche Fehler enhalten), aber auch die Ausgabe von find per pipe (dann ist der Name "natürlich" '-', was bei einer(1) Eingabe aber auch nicht schlimm ist). Zusätzlich druckt der Einzeiler die Zeilen-, die Spaltenummer und die Zeile selbst aus, damit solltest du leicht den Pfad erkennen. Gruß Jan -- Sooner or later, the worst possible set of circumstances is bound to occur.
Hallo Liste, Am Sonntag 8 Januar 2006 00:38 schrieb Bernd Kloss:
Helga Fischer
schrieb am 08.01.06 00:16:02:
[...]
Schuld daran ist 'o� L�ung.html' (mittels C&P hier mal eingefügt), nur habe ich überhaupt keine Ahnung, wie ich nun herausfinden soll, wo der Störenfried sich versteckt.
[...]
Hallo, Helga, das hatten wir gerade vor ein paar Tagen. Ich habe diese Probleme gehabt und habe sie tw. immer noch.
Konqueror ließ sich nun doch überreden, die Datei zu finden, wobei ich radikal abgekürzt habe, so wie von Bernhard empfohlen. Gestern Nacht habe ich vielleicht im falschen Verzeichnis gesucht, das weiß ich nicht mehr oder das Abkürzen hat geholfen.
Ja, der Umstieg auf utf8 ist sowieso nicht mehr zu verhindern ;);)
Das weiß auch die Suse-sdb, daher noch der Link, den ich mir klugerweise irgendwann mal gebookmarkt hatte, wohl wissend, dass der Umstieg auf utf8 für gemütliche Abende sorgen könnte ;) : http://portal.suse.com/sdb/de/2004/05/jbartsh_utf-8.html Helga -- ## OpenSource-Werkstatt in Reutlingen -- http://www.eschkitai.de/ ## Etikette - Nein Danke? -- http://www.suse-etikette.de.vu/ ## Wer hilft? -- http://hsqldb.sourceforge.net/web/openoffice.html ## Vote for: http://bugs.kde.org/show_bug.cgi?id=77109
participants (4)
-
Bernd Kloss
-
David Haller
-
Helga Fischer
-
Jan Ritzerfeld