[Gelöst] HEX-Editor der Ausschnitte lesen kann oder andere Dateischnitt-Varianten

[buhtz]

Ich habe hier eine mehrere GB große CSV-Datei (~ 50 Mio Zeilen) mit einem "mysteriösen" Zeichen drin, welches das Einlesen der Datei mit diversen Programmen verhindert.
Nach vielen Stunden kann ich die Zeile genau benennen.

Nun brauche ich einen Hex-Editor, dem ich beim Öffnen schon sagen kann, dass er sich nur 3 Zeilen dieser Datei anschauen soll. Das Navigieren in einem Hex-Editor würde mit 50 Mio Zeilen unpraktikabel werden.

Frage: Diese Frage hier bezieht sich wirklich nur auf den Editor. Das mit dem Zeichen würde ich dann ggf. in einem neuen Thread berichten oder erfragen, wenn ich meine Diagnosemöglichkeiten ausgeschöpft habe.

Solche Dinge wie split sind keine Lösung, weil ich in den Dateiteilen das Problem nicht reproduzieren kann. Scheinbar macht split hier schon irgendeine Konvertierung. Tatsächlich löse ich aktuell das Problem damit, dass ich die Datei splitte und dann wieder per cat zusammenfüge. Dann geht das Einlesen (z.B. in R, Python, Emacs, etc). Ein diff beider Dateien führt bei mir zu einem "Getötet.". Könnte daran liegen, dass ich das auf einem Raspberry Pi 4 mache. Heute Abend habe ich eine bessere Maschine zur Hand und probiere nochmal ein Diff. Der Output vom Windows-eigenen LC zeigt mir genau die betreffende Zeile an, aber nicht das eine Zeichen. Werde da nicht schlau draus.

Alternative Frage: Ich probiere gerne noch andere Datei-Schnitt oder Datei-Ausschnittsvarianten aus. Es müsste halt möglichst ohne irgendwelche Konvertierungen geschehen, damit ich auch im Ausschnitt das Problem reproduzieren kann.

[tobo]

Was ist, wenn du dir mit sed die Zeile greifst und nach od pipest?

Code: Alles auswählen

sed -n Np FILE | od -c

N ist die Zeilenummer und FILE der Dateiname. Oder halt mit deinem Zeilenbereich:

Code: Alles auswählen

sed -n N-1,N+1p FILE | od -c

[buhtz]

Sehr sehr spannend. OK, bleiben wir gleich hier mit dem "mysteriösen Zeichen", weil es so gut funktioniert.

Code: Alles auswählen

sed -n 15588840,15588845p FILE.csv | od -c
0000000   F   2   6   6   F   6   5   0   9   2   A   E   2   0   F   D
0000020   0   1   0   B   C   4   D   3   9   9   B   5   F   D   7   6
0000040   8   1   9   E   3   6   A   4   ;   2   0   1   8   0   9   2
0000060   5   ;   0   2   ;   E   D   A   C   9   4   0   5  \0  \0  \0
0000100  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
12054045760  \0  \0  \0
12054045763

OK, was sagen mir diese \0? Bin unsicher, ob diese Nullen bis zum Dateiende gehen. Ist dieser sed Befehl richtig?

Code: Alles auswählen

sed -n "15588840,$ p" FILE.csv | od -c

Wenn ja, dann kann ich sagen, dass es der Selbe output ist. Also gehen die Nullen wohl bis zum Dateiende.

Nebeninfo:
Laut wc -l hat die Originaldatei 15.588.839 Zeilen. Aber die per split und dann wieder cat erzeugte Datei hat dann plötzlich 26.362.385 Zeilen.
Das widerspricht der Hypothese die Datei sei mit diesen Nullen aufgefüllt.

Woher diese Nullen kommen, werde ich natürlich den Datengeber fragen müssen; was sich hinziehen wird. Interessant ist, dass das Problem mitten in einem Feld auftaucht und nicht am Rand des Feldes oder einer Zeile.

[Livingston]

\$, nicht $, sonst wird $p von der bash als leere bzw. nicht vorhandene Variable behandelt:

Code: Alles auswählen

sed -n 15588840,\$p FILE.csv | od -c

[buhtz]

\$, nicht $, sonst wird $p von der bash als leere bzw. nicht vorhandene Variable behandelt:

Code: Alles auswählen

sed -n 15588840,\$p FILE.csv | od -c

Danke sehr. Auch so bleibt der output der Selbe. Interepretiere ich sed hier korrekt: Die letzte Zeile ist 12.054.045.660 Zeichen lang?

Nach meiner Interpretation gibt es zwei Widersprüchliche Hinweise.

1. Der sed-Output deutet darauf hin, dass ab dem "Problemzeichen" alles nur noch mit \0 aufgefüllt ist, bis zum Dateiende.

2. Meine Kombination aus split und cat zeigt aber etwas anderes. Die ca. 15 Mio. Zeilen der Originaldatei werden danach zu ca. 26 Mio. Zeilen. Die Originaldatei konnte ich in R (und diversen anderen Anwendungen) nicht einlesen. Bei R kam der Hinweis, dass das Feld bei 2048MB sein Limit erreicht hat. Die neue Datei (nach split/cat) kann ich aber Problemlos einlesen. Der Inhalt ist valide. Ich sehe über die Problemzeile # 1.558840 hinaus valide Werte in allen Spalten. Auch am Ende des DataFrames (per tail) sieht alles ordentlich aus.

Könnte es sein, dass sich hinter der \0 doch mehr Informationen verbergen, als der sed/od Output vermuten lässt?
Und warum tut split die Datei scheinbar reparieren?

[Livingston]

Alles schwer zu sagen. Jedenfalls geht sed immer zeilenweise vor und hangelt sich von Zeilentrenner zu Zeilentrenner durch, also von "\n" zu "\n". Bei meinen eigenen txt-Dateien, die ich zum Testen verwendet habe, klappt auch alles anstandslos.
Im übrigen "berechnet" sed mit dem Marker $ nicht erst die letzte Zeilennummer, sondern arbeitet stur Zeile für Zeile weiter, bis es vom Dateiende "überrascht" wird.

Es ist also gut möglich, dass der sed-interne Puffer irgendwann überläuft, wenn Millionen von Nullen aufeinanderfolgen.

[tobo]

So ein NUL-Zeichen hat in einer Textdatei überhaupt nichts zu suchen. Erstmal solltest du rausbekommen, ob sich das über Zeilenenden erstreckt:

Code: Alles auswählen

sed -n '/\x0$/=' FILE.csv

[buhtz]

So ein NUL-Zeichen hat in einer Textdatei überhaupt nichts zu suchen. Erstmal solltest du rausbekommen, ob sich das über Zeilenenden erstreckt:

Code: Alles auswählen

sed -n '/\x0$/=' FILE.csv

Die Ausgabe hier ist schlicht

Code: Alles auswählen

15588840

EDIT:
Den Trick mit split und cat aus 15 Mio plötzlich 26 Mio zu machen, die auch noch bis zum Ende durchgehend valide CSV-Daten enthalten, kann ich heute Abend auf einer zweiten Maschine (i686, Debian11) nicht reproduzieren. Die letzte Zeile mit den \0 bleibt erhalten.
Vorher hatte ich das auf einem RapberryPi 4 gemacht; auf den ich leider erst Montag wieder Zugriff habe, um eine Reproduktion zu versuchen.

[Livingston]

Das ist doch schon mal was: Die Ausgabe besagt, dass genau eine kaputte Zeile mit NULlen existiert, auf die ein Zeilenende-Zeichen "\n" folgt, nämlich Zeile Nr. 15588840.
Jetzt könntest Du noch nach anderen Zeilen mit Nullen suchen, auf die u.U. noch reguläre Daten folgen, bevor sie mit einem Zeilenende abgeschlossen werden:

Code: Alles auswählen

sed -n '/\x0/=' FILE.csv

also das Ganze nochmal ohne "$" im Suchbegriff.
Sollte diese Ausgabe ebenfalls nur 15588840 beinhalten, dann weißt Du, dass es nur diese eine Zeile mit irregulären Daten gibt, und kannst die NULlen mit

Code: Alles auswählen

sed '15588840s/\x0*//g' FILE.csv > SAUBER.csv

löschen und gleich alles in eine bereinigte Datei packen. Die Daten am Zeilenbeginn und eventuell vorkommende Daten zwischen den NUL-Zeichen bleiben übrigens erhalten, und nur die NUL-Zeichen werden entfernt.

Was den Krempel mit split angeht: Keine Ahnung, ob es mit solch pathologischen Dateien klarkommt. Wahrscheinlich sollte man es nur auf gesunde Dateien loslassen.

[buhtz]

Ich danke euch sehr für eure Hilfe und Geduld. Ich denke jedoch, wir können das hier schließen.

Kurz gesagt, gehe ich nun davon aus, dass ich die Datei während eines Kopiervorgangs (vermutlich USB) korrumpiert habe.

Durch gewisse Restriktionen meiner Arbeitsumgebung (OS, Admin, Speicher-Quota, usw) war ich gezwungen die gelieferte Originaldatei mehrfach hin- und herzukopieren (per Netzwerk und auch USB-Stick). Das mit split und cat erklärt sich vermutlich so, dass zum Zeitpunkt des allerersten split, die Datei noch intakt war und diese erst danach (durch weitere Transfers) kaputt ging, jedoch die split-Teile intakt blieben. So erklärt es sich, dass ein cat auf die split-Teile zu einer intakten Datei führt.

Sicher kann man natürlich nicht sein, weshalb ich den Datengeber, um eine neue Datei bitten werde.

[tobo]

Sollte diese Ausgabe ebenfalls nur 15588840 beinhalten, dann weißt Du, dass es nur diese eine Zeile mit irregulären Daten gibt, und kannst die NULlen mit

Code: Alles auswählen

sed '15588840s/\x0*//g' FILE.csv > SAUBER.csv

löschen und gleich alles in eine bereinigte Datei packen.

Was ja auch "kein" \x0 löscht - Bei relevanten Daten wäre sowas bestenfalls langsamer, wenn etwas in der Ersetzung steht, dann falsch. Besser \x0\x0* oder \x0\+ (siehe echo abc | sed 's/\x0*/X/g').