JPG avec le bloc-notes, Collé tout le "texte" dans le nouveau fichier du bloc-notes, a changé pour le .JPG et ne veut plus. Pourquoi?
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 pourrait simplement choisir d'ouvrir le fichier JPG avec notepad, 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 vierge TXT et je l'ai enregistré au format JPG. J'ai comparé la nouvelle taille du fichier au fichier JPG d'origine. Tous (le fichier JPG d'origine, le fichier TXT converti et le fichier TXT nouvellement créé) sont de la taille exacte même taille, en octets.
Lorsque j'essayais d'ouvrir, Windows disait "La Visionneuse de photos Windows ne peut pas ouvrir cette image car le fichier semble être endommagé, corrompu ou trop volumineux" .
J'ai même essayé de le tester en utilisant une autre méthode: J'ai ouvert le JPG avec le bloc-notes, j'ai coupéUN/ caractère connu depuis un emplacement facile à mémoriser (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 auEXACTemplacement (le Bloc-notes se souvient de son état de sortie, comme la position de la fenêtre, le retour à la ligne, 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 l'encodage 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 à 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. Seulement 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 de conversions de caractères à un octet en séquences à plusieurs 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, le BOM .
Pourquoi ça échoue:
Le bloc-notes crée des espaces (ASCII code 32) caractère pour des caractères tels que NUL(ASCII code 0) car la zone de texte de l'API Windows n'autorise que char * terminé _ (_) ASCIIZ (tableau de caractères, pointeur). Il est coupé à la première NUL.
Cela est dû au fait que l'API Windows est principalement écrite en langage C et que les chaînes terminées null sont l'une des fonctionnalités courantes. 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 du type incomparable (commercial, essai) pour voir l’effet de remplacement du personnage. voir aussi autres outils de comparaison binaires .
Note: (20)16 = (32)dix
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 similaire linker )
J'utilise l'outil PEiD (qui a arrêté le développement avec l'introduction de PE +/64 exes)
PEiD peut être trouvé dans le dossier bin de Universal Extractor
J'ai extrait le bloc-notes. ex_ fichier 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 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 la fin de ligne de style UNIX LF que Bloc-notes convertira en CRLF et null (0x00) et qu'il va ignorer. 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 visionneuse/é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 ont eu des problèmes avec le copier/coller des premiers octets, le nombre magique de signatures 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. Ecrire permettant le montage en toute sécurité binaire d'un fichier, il pourrait ouvrir (taille de fichier probablement très limité). 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 très vieux Windows) et essayer à nouveau l'expérience!
Selon l'article "Windows Write" de Wikipedia Write a été inclus jusqu'à Windows NT 3.5. Il a été remplacé par Wordpad sous Windows 95 partir. write.exe était encore présent dans le répertoire Windows, mais était simplement un emballage 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
encoder 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.