Dateien inhaltlich vergleichen

[Ralph Erdt (2)]

Auch "Klartext" ist codiert. Wobei der Unterschied mit bloßem Auge tw. kaum zu erkennen ist, aber verschieden codierte Dateien (also binär unterschiedlich) zum gleichen Anzeigetext führen können.

ASCII, ANSI, CP437, CP850, CP1252, CP1000, ISO-8859-1, ISO-8859-15, UTF16, UTF32, UTF8, ...
Nur um die wichtigsten zu nennen, mit denen ich mich schon aktiv rumschlagen musste. Da ich anhand der Frage annehme, dass der OP noch am Anfang seiner Informatik-Karriere steht, habe ich mal den Teil übersprungen und etwas "Grundlagen" erläutert.

@OP: Was wir gerade diskutieren:
Eine Computer kennt nur Zahlen. Text im dem Sinne kennt ein Computer nicht! Aber um von Zahlen zu Text zu kommen (ganz platt ausgedrückt) gibt es Listen, welche Zahl welches Bild (!!) erzeugen soll. Ein Computer geht also nur hin und setzt dann entsprechende Bilder auf dem Monitor. Und es gibt zig unterschiedliche Listen (siehe meine kleine Aufzählung oben).
Zum besseren Verständnis eine kurze Historie (@Geeks: Wenn ich Fehler mache, bitte korrigieren!):
Historisch hat sich irgendwann rausgebildet, dass ein Byte 8 Bit sind (ursprüngliche Fernschreiber (18xx) haben noch mit 6 Bit gearbeitet!). Anfang hatte man aber ein Bit als Sicherheit definiert (Parity Bit), so dass man 7 Bit = 128 Zahlen (0-127) hatte. Somit konnte man 128 Zeichen definieren. Anfang hatte jede Firma seine eigenen Zeichen definiert. Dann wurde der ASCII Code definiert. 0-31 waren Steuerzeichen (z.B. 'neue Zeile' (line feed), 'Wagenrücklauf' (carrige return)). Darüber kamen die Zahlen, Buchstaben, Satzzeichen und einige graphische Elemente.
Später war der Speicher so gut, dass man kein Sicherheitsbit mehr brauchte. Dadurch hatte man doppelt so viel Zahlen / Zeichen zur Verfügung: 2^8 = 256 Zahlen / Zeichen. Im ANSI Code wurden der obere (neue) Bereich hauptsächlich mit graphischen Schnick/Schnack gefüllt.

Aber es hatten schon lange die Länder mit Sprachen, die zwar vom Lateinischen kommen aber erweitert wurden Probleme mit ASCII/ANSI. Deren 'Sonderzeichen' kamen in dem Code nicht vor. Z.B. im deutschen die Umlaute (äöüÄÖÜ) (Das 'Esszet' (ß) wurde mit dem griechischen Beta Zeichen umgesetzt). Daher haben die Informatiker in diesen Ländern einfach einige Zeichen im oberen Bereich umdefiniert. Also neues Bild für die Zahl.

VGA Karten, die damals aktuell waren, haben es erlaubt, dass man die Bilder dynamisch ändern konnte (hatte ich damals für ein Spiel genutzt!). MS-DOS konnte daher unterschiedliche "Codepages" für die unterschiedlichen Länder laden. (CP437, CP850 für Deutschland - unterschied war IMHO das 'ß'. Wie genau, weiß ich jetzt nicht mehr). Windows (3.x) hatte dann die CP1252 verwendet.

Irgendwann wurden dann verschiedene Codepages ISO standardisiert (8859). Diese wurden dann im dem aufkommenden Internet verwendet, indem man am Anfang der Web Seite geschrieben hat, in welcher Codepage die Seite ist, so dass der Browser die verschiedenen "Bilder" nutzen konnte. Wichtigste (für uns): -1 für Latin1 (Westeuropa) und später -15 (Latein 1 mit Euro-Symbol).

Da es aber krampfig ist, für jede Webseite einen anderen Bilderset zu haben, hat sich ein Gremium/Konsortium gebildet, welches ALLE Zeichen auf der Welt in einem Zeichensatz vereinigen wollte (Englisch, Europäische Zusatzzeichen, kyrillisch, griechisch, chinesisch, etc.): Unicode. Dafür hat man dann gesagt, wir nehmen 2 Byte (16 Bit) pro Zeichen und hat munter definiert (UTF-16). Leider hat das nicht ausgereicht, so dass man a) UTF-32 (4 Byte pro Zeichen) definiert hat und b) UTF-16 umdefiniert hat, so dass es nun variable Länge hat und so auch alle Zeichen speichern kann. Und bei dem Schwachsinn (persönliche Meinung) den die da aktuell noch hinzufügen, wird das auch nicht reichen.

Problem für uns Europäer: 4 (2) Byte für Text, wo 99,9..% des Textes nur Ein Byte braucht und der Rest der Byte Null ist: Platzverschwendung hoch vier. Daher hatte man UTF-8 definiert, bei dem die Anzahl der Zeichen dynamisch ist. Aber DAS zu erklären führt hier und jetzt zu weit.

State of the Art ist bei Windows UTF-16 (Wide Character). Moderne FS in Linux etc. nutzen UTF-8.

Dies ist nur eine sehr kurze und stark unvollständige Übersicht. Unicode für sich ist weitere "Übersichten" wert..

Was bleibt für Dich (den OP) zu beachten: Erstmal nichts. Mach einfach weiter wie gehabt. Wenn du später Probleme mit Umlauten bekommst (die werden falsch dargestellt), dann lohnt sich da weiterdenken.


Edit:
* "Parity Bit" eingefügt - ist mir jetzt eingefallen
* Codepagenummern nach Hinweisen von Wernfried korrigiert. Danke. "Dies ist nur eine sehr kurze und stark unvollständige Übersicht. Unicode für sich ist weitere "Übersichten" wert.." eingebaut
* UTF-16 längenvariabel eingebaut.

[defo]

Wie mein Vorredner andeutete:
.TXT liegen "plain" - also Kalrtext - auf der Platte.

Auch "Klartext" ist codiert. Wobei der Unterschied mit bloßem Auge tw. kaum zu erkennen ist, aber verschieden codierte Dateien (also binär unterschiedlich) zum gleichen Anzeigetext führen können.

Man ist (hier in D) wahrscheinlich daran gewöhnt, ASCII oder eine 8 Bit Erweiterung davon als "Urzustand" eines Textes wahrzunehmen. In Amerika reicht etwas weniger eben der 7er Code und die Chinesen können das kaum gebrauchen.

[Ralph Erdt (2)]

Wie mein Vorredner andeutete:
.TXT liegen "plain" - also Kalrtext - auf der Platte.

Bei anderen Dateiarten ist der Inhalt in irgendeiner Form codiert. Es liegt ja nicht nur der Text vor, sondern auch Formatierungsinformationen, Seiteninformationen, Meta Daten (Autor, ..) etc. Als Beispiel einfach mal eine .docx nehmen und zu "zip" umbennen und dann mal reinsehen. Hier sieht man sehr schön, was alles abgespeichert wird. ACHTUNG! Der "Trick" geht nur bei bestimmten Dateien! Andere Formate werden anders abgespeichert - je nachdem, was sich der Hersteller gedacht hat. Anderer Tip: öffne mal ein PDF in Notepad. Da sieht man teilweise Anweisungen. Noch ein Tip: öffne mal verschiedene Dateien in Notepad (oder besser: In einem Hex-Editor) uns sieh dir die ersten paar Zeichen an (und dann google mal nach "Magic Numbers"). Vergleich spaßeshalber mal die ersten beiden Zeichen von .EXE und .DLL -> ja, das sind die gleichen Dateitypen!

Zum Thema: Da - von TXT Dateien abgesehen - die Dateien nicht als Klartext abliegen, sondern in irgendeiner Form codiert sind, kann man nicht so naiv die Texte laden. Es kann durchaus sein, dass zwei verschiedene Speicherungen hintereinander eine (binär) komplett andere Datei ergeben! Wenn du also ein Textvergleich machen willst, musst Du vorher die Datei entsprechend dem Format laden und den Text extrahieren. Entweder findest du Bibliotheken die das können (wie schon bei dem einen Link), oder du implementierst das selber. Letzeres ist harte Kost (zumal die Dokumentation zu .docx Dateien wohl einige Tausend Seiten umfasst und nicht vollständig geklärt ist. Und dass es eine Dokumentation gibt liegt daran, dass MS das Dateiformat Standardisieren will / wollte (wie ist da eigentlich der Stand?) um den OpenDocument Format (.od?) Konkurrenz zu machen. Es gibt für viele Formate schlicht keine Dokumentation).

Viel Erfolg bei dem Vorhaben! Auch ich arbeite z.Zt. an einem Projekt, bei dem andere Leute mir den Scheibenwischer zeigen... :-)

[Christian Marquardt]

Wie kommst du auf die Idee, dass eine *.pdf mit einer *.docx Datei in irgendeiner Form identisch sein könnte?

Warum sollte man Binärdateien mit ASCII vergleichen?

Die Dateien könnten kodiert sein, verschlüsselt sein, oder die Bytes liegen in einem Codeschema vor (bsp. UTF-8,16 o.a.).
Die unterschiedlichen Anwendungen, werden auch die Daten in unterschiedlichen Formaten speichern.
Wenn bsp. zu jedem geschriebenen Buchstaben/Buchstabenblock vorab die Formatdaten liegen, wirst du keinen Text erkennen können.

Diese Art des Vorgehens würde ich überdenken.