Decodierung eines Win10-outputs mit cp852 ist ok, mit cp1252 nicht

[ulipy]

Hallo,
ich komm einfach nicht weiter mit diesem meinerseits sehr ungeliebten Thema (codecs) und frage mich, ob jemand helfen kann?
Ich versuche, eine von Win10 erzeugte Datei einzulesen.

Die Test-Datei enthält div. Umlaute sowie "ß".
(Diese Zeichen stehen ursprünglich in Dateinamen - dort würde man diese nicht haben wollen, normalerweise..)

Die Test-Datei wird von Win10 erzeugt:

• dir /s > test-list.txt

Weit weg von "Durchblick" kann ich sagen:

Ausgangslage:
* Win10, deutsch als Sprach-Grundeinstellung
- weitestgehend Standard-Installation
- insbesondere keine beabsichtigten Veränderungen an irgendwelchen codecs, welche von Windows als Default(s)verwendet werden

Das Problem:
Die Umlaute etc. in der mit dir /s > test-list.txt erzeugten Datei lassens sich mit cp852 korrekt / lesbar einlesen, mit cp1252 jedoch nicht.

Es wurde jedoch (hier) verschiedentlich gesagt, dass Windows den output in cp1252 codieren würde.

Diesen (scheinbaren?) Widerspruch kann ich nicht auflösen - was mach ich hier falsch??

[pillmuncher]

Google ist hier ausnahmsweise mal dein Freund. Ich jedenfalls habe damit sofort das hier gefunden:
https://stackoverflow.com/questions/629 ... 0-terminal

[Sirius3]

@ulipy: Konsolen-Umleitungen sind unter Windows sehr unüblich. Eine Konsole hat als Default-Encoding cp852, an anderen Stellen ist das Default-Encoding vielleicht cp1252. Kommt halt auf den Fall an.
Wenn es um Dateinamen geht, würde man aber eher direkt die Verzeichnisse mit den passenden Funktionen lesen.

[ulipy]

@pillmuncher
super danke - hatte die "falsche(n)" Fragen gestellt, da das Problem der Rückwärts-Kompatibilität nicht auf dem Radar war...

@Sirius3
Ja, wenn irgend möglich wird das ohne jegliches Zögern vermieden - bin dabei, einen größeren Dateibaum (> 1.000.000 Einträge) in die Weiterverarbeitung zu bekommen.

An dieser Stelle spielt leider die Laufzeit die entscheidende Rolle und in die BS-internen allocation table(s) werde ich nicht eingreifen wollen.

[ulipy]

und auf anderem Weg wüßte ich (noch?) nicht: wie machen?

[Sirius3]

Du suchst pathlib.Path.rglob.

[pillmuncher]

@ulipy: Welche falsche Frage hast du Google denn gestellt? Meine war: "windows 10" "cp852". Der Link oben war das zweite Ergebnis.

[ulipy]

@Sirius3
danke für den Tip - hatte dies bisher nicht gekannt - ist sicher das "Beste" für die hauptsächliche, allerdings erst im nachfolgenden Schritt geplante Detail-Analyse des Verz.-Baums (einschl. Dateien).

Jetzt konnte ich sehen, dass der Aufruf ein "generator object" zurückgibt - dies scheint für den ersten Schritt nicht das Richtige.

Es geht im ersten Schritt für eine grobe Abschätzung der "Mengen" lediglich um diese Übersichts-Informationen:

dir C:\ /s > dir_C_s.txt
...
...
Anzahl der angezeigten Dateien:
914275 Datei(en), 292.203.259.623 Bytes
612829 Verzeichnis(se), 196.440.002.560 Bytes frei

Execution time in seconds: 132.6129128932953

2.344.935 lines in output file
(bei einem großen Baum)

Die bisherigen Tests sowohl mit Win-Konsolen- als auch mit Py-Mitteln zeigten bisher einen erheblichen Laufzeitunterschied von ca. 130 (Win) und ca. 299 sec. (Py [glob]).

Bei "kleinen" Bäumen spielt dies natürlich kaum eine Rolle - bei größeren schon. Da "sitzt" Win näher an den Quell-Informationen, denke ich.

@pillmuncher
hatte Windows als Verursacher des Problems nicht gezielt in die Suche einbezogen - dann kommen beim Thema codecs gerne auch mal tausende (für mich) schwer nachvollziehbare bzw. verwendbare Vorschläge...

[__blackjack__]

@ulipy: Ich finde den Laufzeitunterschied jetzt nicht wirklich schlecht. Du vergleichst da ein in C oder C++ geschriebenes, seit Ewigkeiten existierendes Programm vom Hersteller des Betriebssystems mit etwas selbst geschriebenen in der wahrscheinlich langsamsten dynamischen Programmiersprache die allgemein verwendet wird und hast nur einen Unterschied der kleiner als Faktor 2,5 ist. Wenn das ein Problem ist, dann ist Python wahrscheinlich nicht die Sprache die Du verwenden solltest/kannst.

[sparrow]

@ulipy: Welche Informationen willst du denn haben? Die reine Anzahl der Dateien und Verzeichnisse?

Insbesondere, weil die Ausgabe von dir mit Vorsicht zu genießen ist:

Code: Alles auswählen

D:\>tree test
Auflistung der Ordnerpfade für Volume D
Volumeseriennummer : 00000011 0F67:51EA
D:\TEST
└───test2

D:\>dir /s test
 Datenträger in Laufwerk D:
 Volumeseriennummer: 0F67:51EA

 Verzeichnis von D:\test

14.12.2021  10:46    <DIR>          .
14.12.2021  10:46    <DIR>          ..
14.12.2021  10:46    <DIR>          test2
               0 Datei(en),              0 Bytes

 Verzeichnis von D:\test\test2

14.12.2021  10:46    <DIR>          .
14.12.2021  10:46    <DIR>          ..
               0 Datei(en),              0 Bytes

     Anzahl der angezeigten Dateien:
               0 Datei(en),              0 Bytes
               5 Verzeichnis(se), 132.366.651.392 Bytes frei

5 Verzeichnisse also... soso.


Und nur damit wir das richtig verstehen: Du lässt einen riesigen Output von dir /s in eine Datei schreiben... um an die letzten 2 Zeilen zu kommen? Indem du die Datei dann in Python liest?

[ulipy]

@__blackjack__
keine Frage - die Geschwindigkeit von glob (im Vergleich zu dir) ist ohne Klagen!

libpath wird danach für die detaillierte Analyse verwendet - eine riesen Erleichtertung - keine String Maniupulationen mehr etc etc. - bin begeistert!

@sparrow
die Frage ist:
wie komme ich am schnellsten zur Anzahl der Verzeichnisse und der Dateien?
Z. B. für den Fall, dass das Verzeichnis "C:" heißt und von einem DAU so gewollt ist?

[sparrow]

@ulipy: So:

Code: Alles auswählen

def count_filesystem_objects(start_path):
    file_count = 0
    dir_count = 0
    for root, dirs, files in os.walk(start_path):
        file_count += len(files)
        dir_count += len(dirs)
    return file_count, dir_count