Ce phénomène m'a laissé des questions à poser.

Voici l'expérience détaillée, mon système d'exploitation est Windows 7 x64 SP1:

• J'ai changé un fichier image (JPG) en TXT en changeant simplement son extension (ou on pouvait simplement choisir d'ouvrir le JPG avec le bloc-notes, même chose)

Cela devrait ressembler à ceci, des séquences de textes étrangement attrayantes, et certaines d’entre elles (très rares) sont réellement significatives, comme dans la capture d’écran ci-dessous "creator: dg-jpeg v1.0 ..."

• J'ai désactivé le retour à la ligne et sélectionné tout le texte à l'aide de Ctrl + A (pour m'assurer que rien ne manque)
• J'ai collé le texte copié dans un autre fichier TXT vierge et je l'ai enregistré au format JPG. J'ai comparé la nouvelle taille du fichier au format JPG d'origine. Tous (le fichier JPG d'origine, le fichier TXT converti et le fichier TXT nouvellement créé) ont exactement la même taille, en octets.

Lorsque j'essayais de l'ouvrir, Windows disait "La visionneuse de photos Windows ne peut pas ouvrir cette image car le fichier semble endommagé, trop corrompu ou trop volumineux" .

J'ai même essayé de le tester en utilisant une autre méthode: J'ai ouvert le fichier JPG avec le bloc-notes, j'ai coupé UN caractère connu d'un emplacement facile à retenir (comme le premier caractère de la deuxième ligne), puis sauvegardé le fichier. Le spectateur afficherait bien sûr le même message. Ensuite, je l'ai rouvert et collé le caractère à l' emplacement EXACT (le Bloc-notes se souvient de son état de sortie, comme la position de la fenêtre, son habillage, la taille des polices ... je n'ai donc aucun problème à obtenir ce droit.)

Et toujours la même erreur. Vous pouvez essayer ceci pour vous faire une idée. N'oubliez pas de choisir une petite image, sinon le Bloc-notes se comportera comme un vieil homme rouillé.

Quelle aurait pu être la cause de ce phénomène?

En fonction du codage utilisé pour ouvrir le fichier, le comportement peut être différent. Mon bloc-notes Windows 7 permet d'ouvrir un fichier en big endian ANSI, UTF-8, Unicode ou Unicode.

J'ai testé ce problème avec une petite image jpeg de 2x2 pixels créée avec gimp et ouvrant et sauvegardant le fichier image avec le codage ANSI. En ouvrant l’image originale et l’image sauvegardée avec un éditeur hexadécimal, je constate que toutes les séquences 00 (deux chiffres hexadécimaux, caractère de contrôle NUL ) ont été converties en 20 (caractère espace).

Remettre dans l'éditeur hexadécimal tous les 20 sur 00 restaure le format d'image.

Je l'ai googlé un peu et je n'ai trouvé aucune référence qui explique pourquoi il le fait. Seule une référence à un message qui en avertit (lien de cache Google, la page n'est pas disponible).

Si vous enregistrez / ouvrez le fichier au format UTF-8, il semble qu'il convertisse toujours les caractères NUL en espaces, mais il augmente également la taille du fichier résultant en raison des conversions de caractères codés sur un octet en séquences multi-octets UTF-8.

Si vous enregistrez / ouvrez le fichier au format Unicode, il semble qu'il convertisse toujours les caractères NUL en espaces, mais ajoute également un octet au début du fichier, la nomenclature .

Pourquoi ça échoue:

Le bloc-notes crée des espaces (ASCII code 32)pour les caractères tels que NUL, (ASCII code 0) car la zone de texte de l'API Windows char * n'autorise que les caractères ASCIIZ à terminaison nulle (tableau de caractères, pointeur). Il est coupé à la première NUL.

Cela se produit parce que l' API Windows est principalement écrite en langage C et que les chaînes terminées par null sont l'une des fonctionnalités communes. Même lorsque Windows et Unicode modernes sont considérés comme identiques, des chaînes terminées par null sont présentes. Donc, le bloc-notes les remplace simplement par un espace afin que vous puissiez voir le fichier complet.

Ainsi, lorsque vous enregistrez le fichier, il est corrompu.

wikipedia-null chaînes terminées

Comment faire des recherches plus poussées:

Vous pouvez utiliser un comparateur comme au-delà de la comparaison (commercial, essai) pour voir l’effet de remplacement du personnage. voir aussi d' autres outils de comparaison binaires .

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

La raison pour laquelle le bloc-notes agit lentement sur les gros fichiers

À la recherche dans Notepad.exe (XP 32 bits)

(Je suppose qu'il est encore écrit en C ++ ou du moins que j'utilise un éditeur de liens similaire )

J'utilise l' outil PEiD (qui a arrêté le développement avec l'introduction de PE + / 64 exes)

Le PEiD peut être trouvé dans le dossier bin d' Universal Extractor

J'ai extrait le bloc-notes. fichier ex_ de l'iso Windows XP évidemment. Essaye le. C'est un extrait de fichier cab utilisant 7z.

Attention ! Votre antivirus peut détecter Universal Extractor / PEiD comme un outil de piratage ou un virus. Ne croyez pas qu'il ne le télécharge pas !!

Informations supplémentaires sur l'API Windows

crédits: Jason C

Ce n'est pas juste la zone de texte; WM_SETTEXT en général ne fournit aucun paramètre pour spécifier la longueur de la chaîne, et les chaînes sont toujours supposées se terminer à null. Vous pouvez toujours créer une zone de texte personnalisée avec un message personnalisé spécifiant la longueur de la chaîne, mais le Bloc-notes et la plupart des autres programmes ne le font raisonnablement pas. De plus, la fonction SetWindowText ne fournit pas non plus de paramètre de longueur.

Le Bloc-notes ne conserve pas tous les caractères spéciaux / étendus exactement tels quels. Je n'ai pas de référence immédiate pour ce problème, mais j'ai constaté que tel était le cas, par exemple, avec un LF de fin de ligne de style UNIX que Notepad convertira en CRLF et null (0x00) et qu'il ignorera. Dans un fichier binaire tel qu'un fichier JPG, le ou les caractères que le Bloc-notes ne conserve pas peuvent se produire de manière aléatoire. Essayez votre expérience avec un éditeur compatible HEX et cela devrait fonctionner alors. Je mettrai à jour ma réponse si je trouve une bonne référence et une fois que j'ai testé un éditeur HEX.

Mise à jour: J'ai essayé quelques éditeurs de programmeurs bien connus, mais un seul d'entre eux a fonctionné immédiatement, HxD de Maël Hörz . Je n'avais jamais utilisé HxD auparavant, mais je l'ai trouvé grâce à une réponse à cet article de Stack, un plugin d'affichage / éditeur hexadécimal pour Notepad ++ .

Les autres éditeurs qui ne fonctionnaient pas après quelques minutes d'efforts étaient Notepad ++, Notepad2 et UltraEdit (v17.3, ancienne version). Quelques-uns d'entre eux avaient des problèmes avec le copier / coller des premiers octets, le numéro magique de signature de fichier JPEG FF D8 FF. Peut-être qu'ils travailleraient avec un peu plus de violon que je n'en ai le temps à présent.

Vous pouviez le faire avec Write dans la journée. C’était un programme standard sous Windows 3.1, mais je ne me souviens pas si Windows 95 l’incluait. Write permettrait une édition binaire sécurisée de tous les fichiers qu’elle pourrait ouvrir (taille de fichier probablement très limitée). Notepad n'est définitivement pas sûr en binaire (le texte reste le même, mais les octets réels des caractères non textuels [par exemple, les codes de contrôle] peuvent changer), c'est pourquoi votre exemple JPG ne fonctionne pas. Essayez d’obtenir une copie de Write (et de très anciennes fenêtres Windows) et renouvelez votre expérience!

Selon l'article "Windows Write" de Wikipedia, Write était inclus jusqu'à Windows NT 3.5. Il a été remplacé par Wordpad à partir de Windows 95. write.exeétait toujours présent dans le répertoire Windows mais était simplement un wrapper pour ouvrir Wordpad.

Je pense que ce n'est pas tant un problème d'encodage que de jeu de caractères. Le format JPG est essentiellement un flux d'octets. Permettant ainsi des caractères non imprimables comme NUL, ETX, STX, SOH, DLE, etc.

Le Bloc-notes Microsoft ne peut pas afficher ces caractères non imprimables. Il peut afficher des espaces réservés comme un espace pour un caractère nul. Ainsi, l’ouverture du fichier avec Notepad n’affiche pas le contenu réel mais le contenu décodé par l’encodage sélectionné (utf-8, utf-16, etc.) et affiché par un certain jeu de caractères (unicode, ascii, etc.) caractères imprimables.

Lorsque vous sélectionnez tout le texte affiché et que vous le copiez dans le presse-papiers, vous ne copiez que les caractères imprimables, y compris les espaces réservés. Ainsi, convertir automatiquement les caractères nuls en espaces et ignorer entièrement les autres caractères non imprimables.

Donc, fondamentalement, vous perdez simplement du contenu en le faisant de cette façon. Si vous utilisez plutôt un éditeur hexadécimal, tout le contenu sera copié.

Mise à jour: la réponse de Bhathiya Pereras est exacte: https://superuser.com/a/782885/322784 Les caractères non imprimables ne sont pas ignorés lors de la copie de texte dans le Presse-papiers.

Le fichier JPEG contient des données non textuelles, à l'exception de certains champs. En principe, toutes les valeurs d'octet comprises entre 0 et 255 seront trouvées, en particulier dans la zone représentant l'image compressée codée contenant des données presque pseudo-aléatoires.

Mais Notepad traitera les données en tant que texte ANSI par défaut. Il fera donc diverses choses qui modifieront les données d'origine, telles que:

• remplacer les octets mappant des caractères spéciaux / non définis / interdits car ils n’ont aucun sens pour un texte ANSI valide

• Encodez les caractères nuls, les séquences de fin de ligne et de fin de fichier selon les conventions Windows / DOS

Ce qui signifie que si vous éditez et sauvegardez les données sous forme de texte, le jpeg sera modifié dans le meilleur des cas et rendu inutilisable dans le pire des cas.