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?
C:\blah>fc file1 file2
Il est possible que les fichiers aient la même taille mais soient différents. (bien que généralement certains changements aléatoires ne tendent pas à laisser un fichier de la même taille mais il pourrait le faire facilement). La commande fc vous sera très utile pour enquêter sur ce qui se passe. Vous pouvez également utiliser la commande xxd, celle-ci est dans cygwin et vient également avec vim7. xxd -p fichier1 Cela va vider l'hex d'un fichier. Vous pouvez comparer l'hexagone des deux fichiers avec cela et fc. Ou même ouvrir l'hexagone dans le bloc-notes et feuilletez les deux fenêtres du bloc-notes avec alt-tab.Réponses:
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 .
la source
byte
. Peut-être que vous pensez à une autre langue. Et les développeurs d'applications peuvent gérer les données binaires comme bon leur semble, y compris l'utilisation de chaînes C s'ils le souhaitent. Comme je l'ai dit précédemment, je peux penser à de nombreux formats de fichiers binaires contenant des chaînes C.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 Windowschar *
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) 16 = (32) 10
La raison pour laquelle le bloc-notes agit lentement sur les gros fichiers
Il vérifie chaque caractère et remplace les caractères spéciaux par des espaces. D'autres logiciels ne font pas de conversions en mémoire (du moins pas primitives sous forme de bloc-notes). Ils rendent simplement les caractères spéciaux différemment. Et ils utilisent des techniques avancées de mise en mémoire tampon.À 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.
la source
WM_SETTEXT
en général, aucun paramètre ne permet de 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.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.
la source
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.la source
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.
la source
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.
la source