Dieses Phänomen hat mir Fragen gestellt.

Hier ist das ausführliche Experiment, mein Betriebssystem ist Windows 7 x64 SP1:

• Ich habe eine Bilddatei (JPG) in TXT geändert, indem ich einfach ihre Erweiterung geändert habe (oder man hat einfach beschlossen, die JPG mit dem Editor zu öffnen, das Gleiche).

Es sollte so aussehen, seltsam aussehende Sequenzen von Texten, und einige von ihnen (sehr selten) sind tatsächlich bedeutungsvoll, wie im Screenshot unten "creator: dg-jpeg v1.0 ..."

• Ich habe den Zeilenumbruch deaktiviert und den gesamten Text mit Strg + A ausgewählt (um sicherzustellen, dass nichts übersehen wird)
• Ich habe den kopierten Text in eine andere leere TXT-Datei eingefügt und als JPG gespeichert und die neue Dateigröße mit der ursprünglichen JPG verglichen. Alle Dateien (das Original-JPG, die konvertierte TXT-Datei und die neu erstellte TXT-Datei) haben die exakt gleiche Größe (in Byte).

Wenn ich versuchte, zu öffnen, sagte Windows "Windows Photo Viewer kann dieses Bild nicht öffnen, da die Datei beschädigt, beschädigt oder zu groß zu sein scheint" .

Ich habe sogar versucht , es zu testen andere Methode verwendet: das JPG mit Notepad geöffnet, schnitt ich ONE bekannt Charakter von einem Ort leicht zu merken (wie das ersten Zeichen der zweiten Zeile) , dann speichern Sie die Datei. Der Betrachter würde natürlich die gleiche Nachricht anzeigen. Dann öffnete ich es erneut und fügte das Zeichen an der EXAKT- Stelle ein (Notepad merkt sich den Ausgangszustand wie Fensterposition, Umbruch, Schriftgröße ... also habe ich keine Probleme, das richtig zu machen).

Und immer noch der gleiche Fehler. Sie können dies versuchen, um auf die Idee zu kommen. Denken Sie daran, ein kleines Bild auszuwählen. Andernfalls verhält sich Notepad wie ein alter, rostiger Mann.

Was könnte die Ursache für dieses Phänomen gewesen sein?

Abhängig von der zum Öffnen der Datei verwendeten Codierung wird möglicherweise ein anderes Verhalten angezeigt. Mit meinem Windows 7-Editor kann eine Datei in ANSI, UTF-8, Unicode oder Unicode-Big-Endian geöffnet werden.

Ich habe dieses Problem mit einem kleinen 2 x 2-Pixel-JPEG-Bild getestet, das mit Gimp erstellt und die Bilddatei mit ANSI-Codierung geöffnet und gespeichert wurde. Wenn ich sowohl das Originalbild als auch das gespeicherte Bild mit einem Hex-Editor öffne, sehe ich, dass alle 00 Sequenzen (zwei Hex-Ziffern, NUL-Steuerzeichen ) in 20 (Leerzeichen) konvertiert wurden.

Wenn Sie im Hex-Editor alle 20 durch 00 ersetzen, wird das Bildformat wiederhergestellt.

Ich habe ein bisschen gegoogelt und keine Referenzen gefunden, die erklären, warum das so ist. Nur ein Verweis auf einen Beitrag, der davor warnt (Google Cache Link, die Seite ist nicht verfügbar).

Wenn Sie die Datei als UTF-8 speichern / öffnen, werden anscheinend immer noch NUL-Zeichen in Leerzeichen konvertiert, die resultierende Dateigröße wird jedoch durch Konvertierungen von Einzelbyte-Zeichen in UTF-8-Mehrbyte-Sequenzen erhöht.

Wenn Sie die Datei als Unicode speichern / öffnen, werden scheinbar immer noch NUL-Zeichen in Leerzeichen konvertiert, aber auch ein Byte am Anfang der Datei, der Stückliste , hinzugefügt .

Warum es fehlschlägt:

Notepad erstellt Leerzeichen (ASCII code 32)für Zeichen wie NUL, (ASCII code 0) da das Textfeld der Windows-API nur nullterminiertes char * ASCIIZ (Zeichenarray, Zeiger) zulässt . Es wird beim ersten NUL abgeschnitten.

Dies liegt daran, dass die Windows-API zumeist in C- Sprache geschrieben ist und Zeichenfolgen mit NULL-Abschluss eine der allgemeinen Funktionen sind. Auch wenn moderne Windows- und Unicode-Versionen als identisch angesehen werden, treten nullterminierte Zeichenfolgen auf. Ersetzen Sie sie einfach durch Leerzeichen, damit Sie die gesamte Datei anzeigen können.

Wenn Sie die Datei speichern, ist sie beschädigt.

wikipedia-null terminierte Strings

Wie man weiter forscht:

Sie können einen unvergleichlichen Vergleich verwenden (kommerziell, Testversion) , um den Charakterersatzeffekt zu sehen. Siehe auch andere binäre Vergleichstools .

Anmerkung : (20) ₁₆ = (32) ₁₀

Grund für Notizblock wirkt sich langsam auf große Dateien aus

Suchen in Notepad.exe (XP 32 Bit)

(Ich gehe mal davon aus, dass es noch in C ++ geschrieben ist oder benutze zumindest einen vergleichbaren Linker )

Ich benutze das PEiD- Tool (das die Entwicklung mit der Einführung von PE + / 64-Exes gestoppt hat)

PEiD befindet sich gebündelt im bin-Ordner von Universal Extractor

Ich zog den Notizblock heraus. ex_ Datei von der Windows XP ISO offensichtlich. Versuch es. Es ist ein Cab-Dateiextrakt mit 7z.

Warnung ! Ihr Virenscanner erkennt Universal Extractor / PEiD möglicherweise als Hack-Tools oder Viren. Vertraue nicht es lade es nicht herunter !!

Weitere Informationen zur Windows-API

Credits: Jason C

Es ist nicht nur das Textfeld; WM_SETTEXT bietet im Allgemeinen keinen Parameter zum Angeben der Zeichenfolgenlänge, und es wird immer davon ausgegangen, dass Zeichenfolgen bei Null enden. Sie könnten jederzeit ein benutzerdefiniertes Textfeld mit einer benutzerdefinierten Nachricht erstellen, in der die Zeichenfolgenlänge angegeben ist, aber Notepad und die meisten anderen Programme tun dies vernünftigerweise nicht. Auch die Funktion SetWindowText bietet keinen Längenparameter .

Notepad behält nicht alle Sonderzeichen / erweiterten Zeichen so bei, wie sie sind. Ich habe keine Referenz für dieses Verhalten sofort zur Hand, aber ich habe festgestellt, dass dies beispielsweise bei UNIX-artigen Zeilenende-LF der Fall ist, die der Editor in CRLF und null (0x00) konvertiert, die er ignoriert. In einer Binärdatei wie JPG können zufällige Zeichen vorkommen, die von Notepad nicht beibehalten werden. Versuchen Sie Ihr Experiment mit einem HEX-fähigen Editor und es sollte dann funktionieren. Ich werde meine Antwort aktualisieren, wenn ich eine gute Referenz gefunden und einen HEX-Editor getestet habe.

Update: Ich habe einige bekannte Programmierer-Editoren ausprobiert, aber nur einer von ihnen hat auf Anhieb funktioniert, HxD von Maël Hörz . Ich habe HxD noch nie benutzt, fand es aber dank einer Antwort auf diesen Stack-Artikel, Ein Hex-Viewer / Editor-Plugin für Notepad ++ .

Die anderen Editoren, die nach wenigen Minuten nicht funktionierten, waren Notepad ++, Notepad2 und UltraEdit (v17.3, ältere Version). Einige von ihnen hatten Probleme mit dem Kopieren / Einfügen der ersten Bytes, der magischen Signaturnummer FF D8 FF der JPEG- Datei . Vielleicht würden sie ein bisschen fummeliger arbeiten, als ich momentan Zeit habe.

Früher war dies mit Write back in the day möglich. Es war ein Standardprogramm in Windows 3.1, aber ich kann mich nicht erinnern, ob Windows 95 es enthielt. Write würde eine binär sichere Bearbeitung aller Dateien ermöglichen, die es öffnen könnte (wahrscheinlich sehr begrenzte Dateigröße). Notepad ist definitiv nicht binär sicher (der Text bleibt derselbe, aber die tatsächlichen Bytes von Nicht-Text-Zeichen [z. B. Steuercodes] können sich ändern), weshalb Ihr JPG-Beispiel nicht funktioniert. Holen Sie sich eine Kopie von Write (und einem sehr alten Windows) und versuchen Sie es erneut.

Laut Wikipedia-Artikel "Windows Write" war Write bis Windows NT 3.5 enthalten. Es wurde ab Windows 95 durch Wordpad ersetzt. write.exewar noch im Windows-Verzeichnis vorhanden, war aber nur ein Wrapper zum Öffnen von Wordpad.

Ich denke, es ist nicht so sehr ein Problem der Codierung, sondern auch des Zeichensatzes. Das JPG-Format ist im Grunde ein Byte-Stream. Dies ermöglicht nicht druckbare Zeichen wie NUL, ETX, STX, SOH, DLE usw.

Microsoft Editor kann diese nicht druckbaren Zeichen nicht anzeigen. Es kann Platzhalter wie ein Leerzeichen für ein Nullzeichen anzeigen. Das Öffnen der Datei mit Notepad zeigt also nicht den tatsächlichen Inhalt an, sondern den Inhalt, der durch die ausgewählte Codierung (utf-8, utf-16 usw.) decodiert und durch einen bestimmten Zeichensatz (Unicode, ASCII usw.) angezeigt wird, mit Ausnahme der nicht druckbare Zeichen.

Wenn Sie den gesamten angezeigten Text auswählen und in die Zwischenablage kopieren, kopieren Sie nur die druckbaren Zeichen einschließlich der Platzhalter. Konvertiert daher automatisch Nullzeichen in Leerzeichen und ignoriert andere nicht druckbare Zeichen vollständig.

Sie verlieren also im Grunde nur den Inhalt, wenn Sie dies auf diese Weise tun. Wenn Sie stattdessen einen Hex-Editor verwenden, wird der gesamte Inhalt vollständig kopiert.

Update: Bhathiya Pereras Antwort ist richtig: https://superuser.com/a/782885/322784 Nicht druckbare Zeichen werden beim Kopieren von Text in die Zwischenablage nicht ignoriert.

Die JPEG-Datei enthält mit Ausnahme einiger Felder keine Textdaten. Grundsätzlich werden Byte-Werte zwischen 0 und 255 gefunden, insbesondere in dem Bereich, der das codierte komprimierte Bild darstellt, das nahezu pseudozufällige Daten enthält.

In Notepad werden die Daten jedoch standardmäßig als ANSI-Text behandelt, sodass verschiedene Aktionen ausgeführt werden, die die ursprünglichen Daten ändern:

• Ersetzen Sie Bytes, die Sonder- / undefinierte / verbotene Zeichen zuordnen, da dies für einen gültigen ANSI-Text keinen Sinn ergibt

• Kodieren Sie Nullzeichen, Zeilenende und Dateiende neu nach Windows / DOS-Konventionen

Das heißt, wenn Sie die Daten bearbeiten und als Text speichern, wird das JPEG im besten Fall geändert und im schlechtesten Fall unbrauchbar.