Datei einlesen macht Probleme

[Pythagoraze]

Hi,
ich hab eine Datei, die ich einlesen und deren Bestandteile ich zerlegen möchte

Code: Alles auswählen

1		http://www.microsoft.com	**********@msn.de	h3dlVaaYWWXkBV5JBfFqZ8CJ4Fdyb06v			AAA	BBB					08.01.2023 - 20.22-21	SIMPLE Profil
2		https://www.google.com	**********	â—1E98FCE1B71232			AAA	BBB					19.11.2019  10:47:06	DEFAULT bis 4.1.2021
3		http://board.******.com	*********	РFDелfdтяо.iºÐ			AAA	BBB					04.01.2019 
3		http://www.gmx.de	**********@gmx.de	WA9XbREdFx4oZlXDuu8UIC6RZsfTVOs4kqR4wSlG4yF			AAA	BBB					19.11.2012  10:47:06	DEFAULT bis 4.1.2021 tab
[...]

hab natürlich erstmal mit
with open(image_path, 'r' ) as f:
eingelesen.
der Knall kam in de Zeile mit dem Passwort zum "board".
Kann das Zeichen nicht interpretieren.
ach, klar, dacht ich, hab ich encoding="utf-8" vergessen.
z.B. with open(image_path, 'r', encoding="utf-8" ) as f:
hm, nee, das isses auch nich.
Dann als binary eingelesen:

Code: Alles auswählen

with open(image_path, 'rb' ) as f:
	content = ( (f.read()))

stri = str(content) # den bytearrayin einen String umwandeln
doch irgendwie wurd ich damit auch nicht glücklich, als ich mit liste= stri.split() nach allem Möglichen (CRLF, space, etc.) splitten wollte, denn
laenge = len(liste) >>> ergibt 1
öh, ich dachte mir das irgendwie nach Zeilen gesplittet. Wenigstens in Zeilen.
-> Wieso sind da alle Zeilenumbrüche verschwunden, wenn ich nen bytearray mit str() konvertiere?
Und ohne str() Konvertiern kann ich das ja nicht bearbeiten, denn das ist ja auch blöd, wenn ich ein bytearray auf vorkommende Zeilenumbrüche ("\n") untersuchen und von Hand zeilenweise in die Liste aufteilen wollte.

(... und wenn/falls ich dann damit fertig bin möcht ich jede Zeile mit ner Schleife auf ein Substringvorkommen abfragen:

Code: Alles auswählen

for j in range(0, len(liste)):
	if liste[j].find("bla") != -1:
		pass

aber das dürfte dagegen vergleichbar recht einfach sein)

Aber erstmal Einlesen ...

Seit 11 Uhr fummmel ich da nun rum und komm auf keinen grünen Zweig.

Hab Ihr einen Tip, wie ich die Datei einlesen kann?

________________
Edit: Sagt mal, ich hab den Text hier teilweise mit bbCode [ b ] und [ /b ] ( also [ / b ] ) formatiert.
Aber hier sieht man nix davon.
[/i] kursiv funktioniert
nur [-b-](ohne Striche) [/b] für bold nicht. Ist was kaputt?

[__blackjack__]

@Pythagoraze: `str()` mit einem `bytes`-Objekt ergibt die Zeichenkettenrepräsentation eines `bytes`-Objekts, und nicht den Text den man da vielleicht daraus dekodieren könnte, wofür man ja eine Kodierung angeben müsste.

Code: Alles auswählen

In [114]: b"line a\nline 2"
Out[114]: b'line a\nline 2'

In [115]: str(b"line a\nline 2")
Out[115]: "b'line a\\nline 2'"

Da ist natürlich kein Zeilenende enthalten sondern die Zeichenfolge \n.

Textdateien sollte, und manchmal *muss*, man mit der Angabe der Kodierung öffnen. Es scheint weder richtig geraten zu werden wenn man es hier weg lässt, noch scheint UTF-8 korrekt zu sein. Also was ist die richtige Kodierung? Das musst *Du* wissen. Wir wissen nicht mal welche Zeichen da tatsächlich stehen, denn auf welchem Wege das in den Beitrag gekommen ist: da kann auch eine falsche Kodierung angegeben worden sein.

[Sirius3]

Eingerückt wird immer mit 4 Leerzeichen pro Ebene, keine Tabs.
Über einen Index iteriert man nicht, sondern über die Elemente der Liste direkt, bzw. über das Dateiobjekt. find benutzt man nicht, weil man dafür den in-Operator verwendet.
Das ganze müßte also ungefähr so aussehen:

Code: Alles auswählen

with open(image_path, encoding="richtiges Encoding") as lines:
    for line in lines:
        if "bla" in line:
            ...

[Pythagoraze]

ja,

ich dachte mir das so, daß ich die Datei in eine Art RawString (ASCII) reinlade,
wo mir gar nichts vom String interpretiert wird (und jedes Zeichen == ein Wert im Bereich von 0-255)
und die Funktion split() oder split("\n") mir alle Zeilen in eine Liste auftrennt und aufteilt. (ggf. auch Leerzeichen, uvm.mit .split() )
und ich dann einzelne Zeilen oder "StringTeilStücke" über die Liste abfragen kann. (z.B. print(liste[4]) )

naja, oder wenn die split()-Funktion den Raw String halt nicht mag,
daß ich dann aber wenigstens den Raw String behalten und auf einzelne Chars zugreifen kann. z.B. Rawstring[5:12]

Die Datei hab ich einfach so hier hereinkopiert.
Die sieht 1:1 so aus. (Hochladen oder Anhängen geht ja nicht, oder?)
Wenn ich die reinen Hexwerte posten würde, wäre das auch 1:1

Das Passwort Ð FDелfdтяо.iºÐ war so kryptisch.

[Sirius3]

Wie schon geschrieben, hilft es nicht viel, nachträglich zu versuchen, irgendetwas zu reparieren. Wenn die komischen Zeichen gültiges UTF8 ist, dann ist die Datei wahrscheinlich UTF8-kodiert, es kann aber sein, dass diese Zeichen vorher schon falsch in die Datei übernommen worden sind. Woher stammt die Datei?

[__blackjack__]

@Pythagoraze: ”RawString (ASCII)” ist Unsinn weil ASCII nur Werte von 0 bis 127 kennt. Und natürlich kann man das als `bytes` einlesen. Und auch `split()` funktioniert da. Musst halt mal die Fehlermeldung anschauen was `split()` *logischerweise* als Argument erwartet.

Die Datei kannst Du gar nicht ”einfach so” hier reinkopiert haben. Die wirst Du ja erst geöffnet haben um was zum kopieren auswählen zu können. Und dabei sind die Bytes in der Datei irgendwie als Zeichen interpretiert worden. Mit einer Kodierung die *wir* nicht kennen, also kann hier auch keiner sagen was da tatsächlich in der Datei an Bytewerten steht, nur beim Anschauen der Zeichen im Beitrag.

Wenn Du die Hexwerte zeigen würdest, *dann* wäre das tatsächlich 1:1.

`split()` ohne Angabe eines Trenners ist übrigens ziemlich wahrscheinlich falsch, denn es scheint es kann auch Leerzeichen im Passwort geben. Und falls es dort auch Tabs geben kann, ist das Dateiformat ein bisschen doof.

[grubenfox]

@Pythagoraze: probiere mal das Modul 'chardet' aus
https://chardet.readthedocs.io/en/latest/usage.html
bzw.
https://github.com/chardet/chardet

[sparrow]

@grubenfox: chardet _kann_ zum richtigen Ergebnis führen. Es kann aber auch völlig daneben liegen. Und da offensichtlich nicht bekannt ist, wie der Inhalt richtig aussieht, wird man das nicht vergleichen können.

@Pythagoraze: Dein Text weiter oben hinterlässt bei mir den Eindruck, dass du davon ausgehst, dass jedes Zeichen ein Byte entspricht. Das ist gerade bei Unicode nicht so.
Am Ende musst _du_ wissen, welches Format die Datei hat. Da du dich aber über den Ursprung auschweigst wird es auch an dir liegen, das herauszubekommen.

[Pythagoraze]

Danke erstmal (allen)

Entschuldigt bitte, daß ich kaum weitere Angaben gemacht habe,
das war keine Absicht. Kann Euren Unmut aber verstehen. Ich hab damals in Panik und Eile gehandelt, beim Erstellen der Datei.

Also so weit ich mich erinnern kann, ist die Datei damals mit Excel "erstellt" worden, da ich damals alle Passworte exportiert hab - ich weiß leider nur nicht mehr, mit welchem Programm (ob schon mit keepass, oder nem vorherigen PWManager. und alle in 1 Datei untergebracht.
Die o.g. Daten (creation/Ablauf-Datum) hab ich geändert/anonymisiert. Nur das PW ist original. Die PW sind natürlich auch längst erstetzt nicht mehr aktuell/ in Gebrauch)
von daher ist es wirklich schwer zu sagen, welches Format die ursprünglich wirklich hatten. Aber ich hatte damals den Spleen - zumindest für einge lokal gebrauchte, dienstliche Passworte (Datenbanken) alles auszuschöpfen. PW zusammengesetzt aus dem Vorrat von 256 Bit je Zeichen. Nicht nur AZaz09+/*#.
Ja, Völliger Blödsinn. Weiß ich (heute). Aber immerhin hatten die schon 20 Stellen und wirklichen Mix.

Da ich das Passwort nie wirklich zu Gesicht bekommen habe (PWmg → port 299→ dB-Programm), kann ich nicht genau sagen, ob es genau "so" aussah. (vielleicht kann ich nochmal auf alten Backup-Festplatten/CDRoms stöbern und die Exporte suchen) - War ja nicht lesbar das PW. Und wurde nur von den Programmen gehandelt.
(meine heutigen PW sind lesbar und dafür aber eh viieeel länger)

Jetzt hab ich die Datei zum Posten hier mit notepadplus geöffnet und das hier in den Browser kopiert.
mutmaßlich ANSI, nehm ich an. Die Datei beginnt mit 0D0A.
Der Export der Programme war glaub ich damals als .csv-Datei (hatte auch Keepass. vor dem xml Addon)
und Import u. Weiterverarbeitung in Excel und dann Export als .csv (TAB als Trenner)
Genau weiß ich das nicht mehr.

Ð FDелfdтяо.iºÐ
D0 20 46 44 D0 B5 D0 BB 66 64 D1 82 D1 8F D0 BE 2E 69 BA D0
steht in der Datei.

Mein Vorgehen wäre nun also gewesen, die Datei (Byte-weise abgespeichert) ebenso in 8-Bit Werten zu verarbeiten und möglichst viele Passworte (nicht alle sind 256-Bit-Werte) und Logins zu historisch "retten" und neu zu ordnen.
Eine 15 MB Datei (csv mit TABulator als Trenner) als gerettetes Backup für alle Fälle ist halt nicht sonderlich handlich.
Einfach um des historischen Willen wegen. Wie gesagt, die Logins/ PW sind über 10-15 Jahre angesammelt und zusammengekommen und seit 2014 nicht mehr in Gebrauch (viele Foren und Emailanbieter, etc. gibt es schon gar nicht mehr )
Also hätt ich nun alle Zeilen (Logins, PW, regEmail, Datum je Zeile) wieder nach 09-TABs getrennt und die Schnipsel weiterverarbeitet.
Ja, ich weiß, war nicht das grandiose, von mir erfundene Speicherformat von mir damals, aber ich hatte keine Zeit. Das mußte schnell gehen, (da der PC abgeraucht war und alles noch rettbare auf den Neuen)

Mich hat halt vorhin gestört, daß Python da hängengeblieben war. An diesen Passworten. (und das sind einige ....)
Dadurch kann ich die Datei nicht weiterverarbeiten.
Klar könnte ich über die ganze Datei mit den 256 Integerwerten der Bytes arbeiten. Find ich aber unhandlicher, und unübersichtlich damit die Daten aufzutrennen
Oder geht das wie anders?
(ich muß mal schauen, PIP funktioniert hier an dem Windowsrechner nicht; vielleicht morgen an nem Linuxrechner, oder ich muß gucken, ob ich die module von Hand mit Thonny/ Python einbinden kann. Danke)
Sichtbarer (zumindest, was Nutzername, Emailadresse, Datum angeht, denn die sind ja immer lesbar gewesen)
Sind ja nur die extravaganten Passwörter, die dazwischen stören. Könnt ich auch überspringen/weglassen, aber das ganz script hängt sich ja auf.

Die o.g. Beispieldaten sind aus unterschiedlichen Zeilen der Datei. Damit Ihr eine Vorstellung habt.
Nicht alle Zeilen enthalten gleichviele Daten oder Tabulator-Trenner.
und nicht überall ist die Reihenfolge konsistent, da die aus verschiedenen PWmanagerdatenbanken (u. Programmen) stammen, die das und den Export unterschiedlich gehandhabt haben.

Unter Delphi (D5) hätt ich nun die Datei in einen (unformatierten) String geladen und den nach Zeilen und dann nach TABs getrennt (die sind ja eindeutig).
Mit Python wollt ich das nun auch so machen. nativ. dacht ich. Also mit built-in Funktionen.

[grubenfox]

PIP funktioniert hier an dem Windowsrechner nicht

Das erscheint mir merkwürdig bzw. kaputt

oder ich muß gucken, ob ich die module von Hand mit Thonny/ Python einbinden kann. Danke)

Code: Alles auswählen

python.exe -m pip install <modulname>

also z.b. für chardet

Code: Alles auswählen

python.exe -m pip install chardet

'von Hand'... in das python, welches eben durch python.exe aufgerufen wird. Zum Python welches von Thonny genutzt wird, kann ich wegen 'hier ist kein Thonny unter Windows installiert' nichts sagen oder vermuten...

[sparrow]

0D0A ist ein Zeilenumbruch unter Windows.
Deine Datei beginnt also mit einer leeren Zeile.

Es bleibt aber die Frage, wie die Datei gespeichert wurde, denn daraus ergibt sich die Kodierung. So wie es keine 1:1 Kopie der Daten ist, wenn du sie in einem Editor öffnest, kopierst und hier öffnest, gilt das auch für das Öffnen und Speichern als die Datei erstellt wurden.
Wenn du also die Datei zB mit dem Editor geöffnet hast, um neue Daten anzufügen, hat der Editor beim Speichern auch kodiert. Oder Excel, oder was auch immer.

[Sirius3]

Das erste Zeichen deines Hexcodes ist falsch und die letzten beiden auch, der Rest ist gültiges Utf8, halt kyrillische Buchstaben:

Code: Alles auswählen

FDелfdтяо.i

Jetzt weiß ich wieder nicht, ob das ein Copy-Paste-Fehler ist, oder ob die Bytes tatsächlich so in der Datei stehen.
Du hast immer noch nicht klar gesagt, ob es einen Dekodierungsfehler gibt, oder ob Dir nur die Zeichen komisch vorkommen.

[__blackjack__]

Es sind also Daten aus verschiedenen Programmen exportiert, mit unterschiedlichen Daten/Reihenfolgen pro TAB-getrennter Zeile, und es ist nichts über Kodierungen bekannt, also mit welcher Kodierung die Daten mal aus den ursprünglichen Programmen exportiert wurden und mit welcher Kodierung das dekodiert wurde um in Excel zu kommen, noch mit welcher Kodierung Excel das dann in die Textdatei geschrieben hat. ”Ansehen” kann man den Daten auch nicht ob sie richtig dekodiert wurden, weil es keine Texte sind wo man beispielsweise an "Peter M³ller" erkennt, dass das falsch ist und eigentlich "Peter Müller" sein sollte.

Wenn das aus mehreren Quellen kommt, kann es ja sogar sein, dass die Datei Daten in unterschiedlich falschen Kodierungen enthält und nicht nur eine Kodierung gefunden werden muss.

Ich würde ja fast sagen das ist ein Fall von: jetzt haben wir gelernt das Backups nur was taugen wenn man auch mal testet ob die Daten auch wieder hergestellt werden können. Geht in diesem Fall nicht wirklich. Jetzt mal mit Kodierungen beschäftigen und diesen Fehler das nächste mal nicht wieder machen.

”ANSI” ist übrigens keine Kodierung. Das ist Microsofts ”Name“ für die in Windows eingestellte (8-Bit-)Codepage. Was immer die auch ist.

Du könntest das als ISO-8859-1 dekodieren, und falsch dekodiertes dann halt auch wieder falsch als ISO-8859-1 kodieren beim schreiben. Das entspricht am ehesten die Daten einfach als ”Bytestrings” ohne Kodierung zu behandeln, wie man das früher in C und Pascal/Delphi gemacht hat. Andererseits wäre das Programm “ehrlicher“ wenn man die Daten tatsächlich als `bytes` behandelt. Wie gesagt, auch da kann man `split()` verwenden um das an Bytesequenzen aufzutrennen in Zeilen und dann Felder pro Zeile.

Wenn die Passwörter tatsächlich *alle* Bytewerte enthalten können, musst Du übrigens mit dem TAB aufpassen, denn das wäre dann ja auch ein Bytewert der *in* einem Passwort auftreten könnte. Wenn man dann das Zeilenformat nicht kennt, weil nicht jede Zeile die gleiche Anzahl von Spalten hat, bekommt man hier auch wieder ein Problem, dass man dann nicht sicher sagen wann ein TAB zum trennen von Spalten ist und was zum Passwort gehört. Allerdings ist das ja angeblich ein Excel-Export, dann müsste es ja auch " um Feldwerte geben, wenn da Trennzeichen enthalten sind. *Und* dann würde sich das `csv`-Modul zum einlesen anbieten. Das würde ich auf jeden Fall mal versuchen. Notfalls mit ISO-8859-1 als Kodierung und TAB als Trennzeichen.

[Pythagoraze]

Danke,

ja

Code: Alles auswählen

with open(file_path, 'r', encoding="ISO-8859-1" ) as f:

hat dazu geführt, daß python das Script nicht wegen Dekodierungsfehlern abgebrochen hat, sondern wie er wartet die Datei einfach eingelesen hat.

Jetzt kann ich sie ja ggf. erstmal anders formtatiert speichern und dann in Ruhe die einzelnen Datensätze herausfummeln und zuordnen.

Ich hatte sogar die Datei vorher nochmal mit Notepadplus (unter Windows) als ANSI/DOS formatiert eingelesen und als UTF-8 gespeichert.
Brach auch immer mit dem Fehler in der Datei codecs.py Zeile 322 ab.
Auch als ich dann mal all jene Passworte mit notepad++ (durch "foofoofoo") ersetzt hatte und die Datei neu als UTF-8 abgespeichert hab, war es
auch immer wieder mit dem Fehler in der Datei codecs.py Zeile 322 abgebrochen. Dabei dachte ich, es müsse nun alles lesbar sein.

Nun geht es aber mit der ISO-8859-1 fehlerfrei.

läuft durch.

läuft

Ja, das mit dem TAB , also \x09 oder \20 space scheint in den PW nicht vorgekommen zu sein.
OK, ich brauch die PW ja auch nicht mehr - war ne bkloppte Idee - wie auch immer, das Einlesen klappt nun.

VIELEN DANK _ALLEN_ ! (v.a. für Eure Geduld! , naja, bin noch newbie, und hab mich zwar schon mit Koflers , Indens und Weigends Kurse/Bücher eingelesen, aber darauf war ich nun nicht gekommen.
Ich dachte, man könne Dateien einfach so in Strings einlesen und die einfach verarbeiten.)

[__blackjack__]

@Pythagoraze: In welcher Zeile in codecs.py das zu einer Ausnahme führt ist nicht so wichtig zu *welcher* Ausnahme das führt, inklusive Information wo in den Daten das passiert, denn Grund und Stelle werden da ja mitgeteilt.

Ein Editor der ”Kodierungen” wie ANSI/DOS ”kennt”, die es so gar nicht gibt, so das man gar nicht weiss was das jetzt den tatsächlich für eine Kodierung ist, würde ich ja wechseln. ANSI ist wie gesagt Windows-Sprech für „welche Kodierung auch immer in Windows gerade eingestellt ist“. Also bei uns in der Regel CP1252. DOS hat auch eigene Codepages. Bei uns oft CP850, aber auch das ursprüngliche, ”amerikanische” CP437 wurde bei uns öfter verwendet. Also weiss man nicht wirklich was ANSI/DOS tatsächlich ist. Und auch nicht wie die Bytewerte interpretiert/angezeigt werden, die in CP1252 beispielsweise gar nicht definiert sind.

[Sirius3]

@__blackjack__: Es ist nicht das Problem des Editors, dass der ANSI unterstützt, sondern sas Problem von Windows. Der Editor nimmt einfach das, was Windows behauptet, was es unter ANSI versteht.

@Pythagoraze: `funktioniert` würde ich eher nicht sagen. Du hast das Problem erfolgreich ignoriert. Ob es Dir später auf die Füße fällt, wirst Du noch sehen.

[__blackjack__]

@Sirius3: Die Zeichenkette "ANSI/DOS" kommt vom Betriebssystem und nicht vom Programmierer des Editors?