Conversion d un fichier *.* en binaire ou hexa
Résolu/Fermé
gama kishi
Messages postés
20
Date d'inscription
dimanche 14 juillet 2013
Statut
Membre
Dernière intervention
10 août 2014
-
25 juil. 2014 à 13:51
gama kishi Messages postés 20 Date d'inscription dimanche 14 juillet 2013 Statut Membre Dernière intervention 10 août 2014 - 26 juil. 2014 à 12:23
gama kishi Messages postés 20 Date d'inscription dimanche 14 juillet 2013 Statut Membre Dernière intervention 10 août 2014 - 26 juil. 2014 à 12:23
A voir également:
- Conversion d un fichier *.* en binaire ou hexa
- Fichier rar - Guide
- Fichier host - Guide
- Fichier iso - Guide
- Comment réduire la taille d'un fichier - Guide
- Comment ouvrir un fichier epub ? - Guide
2 réponses
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
25 juil. 2014 à 16:18
25 juil. 2014 à 16:18
Bonjour,
j'ai du mal à comprendre où vous pouvez bien bloquer, puisque peut importe le format du fichier finalement, il suffit de l'ouvrir et de le lire en tant que fichier non formaté et voilà...
Et tout fichier est binaire finalement, il n'y a rien à convertir!
Par ailleurs, binaire et héxa sont strictement identique en terme d'informations, l'héxa consistant simplement en une représentation différente du binaire, afin d'être plus lisible.
Et si vous évoquez les fichiers *.* et *..* de racine de répertoire windows, il est normal de pas pouvoir les manipuler normalement puisque windows vient interférer, ce sont des fichiers internes au système!
Par simple curiosité, qu'elle base avez-vous adopté pour compresser sans perte? Je suppose que c'est un dérivé d'un algo existant?
j'ai du mal à comprendre où vous pouvez bien bloquer, puisque peut importe le format du fichier finalement, il suffit de l'ouvrir et de le lire en tant que fichier non formaté et voilà...
Et tout fichier est binaire finalement, il n'y a rien à convertir!
Par ailleurs, binaire et héxa sont strictement identique en terme d'informations, l'héxa consistant simplement en une représentation différente du binaire, afin d'être plus lisible.
Et si vous évoquez les fichiers *.* et *..* de racine de répertoire windows, il est normal de pas pouvoir les manipuler normalement puisque windows vient interférer, ce sont des fichiers internes au système!
Par simple curiosité, qu'elle base avez-vous adopté pour compresser sans perte? Je suppose que c'est un dérivé d'un algo existant?
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
26 juil. 2014 à 12:02
26 juil. 2014 à 12:02
D'accord, alors en fait c'est simplement qu'il faut éviter l'étape hexadécimale!
Il est à peu près inutile de visualiser les données à compresser dans le but de faire des estimations, puisque c'est très laborieux et que l'ordinateur le fait tellement mieux que nous!
Donc il faut oublier l'éditeur hexa et passer direct à la programmation! Bon c'est dommage parce que je ne connais pas le C, mais il suffit d'ouvrir le fichier, de le lire en tant que données non formatées, et d'appliquer l'algo directement sur ce bloc de données brutes!
Ensuite si on souhaite visualiser le comportement de la compression, il suffit d'afficher des informations pertinentes émanant de l'algo sous forme graphique, ou de texte à la rigueur...
C'est à dire qu'en tant qu'humain on peut guère voir grand chose, que des détails par ci par là, alors que l'ordinateur nous permet d'afficher des informations bien plus lisibles, des statistiques ou des paramètres évolutifs en fonction de l'avancée dans le fichier...
Ensuite, binaire ou hexa, peu importe! L'hexa n'est utile que pour visualiser plus clairement 4 bits, rien de plus! Il faut avouer que $3FC7 est bien plus lisible que b11111111000111! Et c'est son seul et unique intérêt!
L'hexa comme le décimal, n'interviennent que lorsqu'il s'agit d'afficher des informations et de les rendre plus lisibles pour l'être humain, autrement dit ces formats n'existent qu'à l'écran, au même titre qu'un texte ou une image, parce que l'ordinateur ne traite rien d'autre que des 0 et des 1!
Donc un fichier n'est qu'un gros tableau de bits!
Par contre selon le type de fichiers, il peut y avoir des alignements qu'il est souvent utile d'exploiter pour compresser: ainsi on trouve très classiquement des alignements sur un octet ou moins, qui va représenter la couleur primaire d'un pixel, un caractère dans un fichier texte...
Les formats de compression les plus simples exploitent généralement cet alignement, c'est le cas du RLE ou du LZW par exemple.
Donc les étapes pour compresser un fichier sont très simples finalement, on l'ouvre, on récupère l'ensemble de son contenu, on applique l'algo sur les données binaires brutes et on retient l'extension.
Ensuite il n'y a plus qu'à décompresser pour retrouver l'ensemble du volume du fichier d'origine, et lui remettre l'extension et voilà!
C'est pas plus compliqué que ça!
Il faut aussi prendre en compte le fait que la plupart des fichiers stockés sont déjà compressés, ce qui rend très difficile le fait de compresser davantage puisque l'information en est très "brouillée"!
Donc idéalement il faut partir d'un fichier non compressé, tel que le wav ou le bmp (en optant pour un bmp non compressé, c'est au choix), ou encore exe, ou bien il est nécessaire de décompresser le fichier via un codec interne avant de travailler sur les données réelles.
Evidemment, un format son ne se compresse pas de la même manière qu'un format image ou exécutable, ou bien avec des résultats très mitigés!
Il faut aussi s'attendre au fait qu'un algo de compression puisque apporter de l'embonpoint au ficher au lieu de le réduire, surtout en compression sans perte!
Ce sera sans doute le cas en appliquant du huffman sur un ficher jpg!
Bon courage!
Il est à peu près inutile de visualiser les données à compresser dans le but de faire des estimations, puisque c'est très laborieux et que l'ordinateur le fait tellement mieux que nous!
Donc il faut oublier l'éditeur hexa et passer direct à la programmation! Bon c'est dommage parce que je ne connais pas le C, mais il suffit d'ouvrir le fichier, de le lire en tant que données non formatées, et d'appliquer l'algo directement sur ce bloc de données brutes!
Ensuite si on souhaite visualiser le comportement de la compression, il suffit d'afficher des informations pertinentes émanant de l'algo sous forme graphique, ou de texte à la rigueur...
C'est à dire qu'en tant qu'humain on peut guère voir grand chose, que des détails par ci par là, alors que l'ordinateur nous permet d'afficher des informations bien plus lisibles, des statistiques ou des paramètres évolutifs en fonction de l'avancée dans le fichier...
Ensuite, binaire ou hexa, peu importe! L'hexa n'est utile que pour visualiser plus clairement 4 bits, rien de plus! Il faut avouer que $3FC7 est bien plus lisible que b11111111000111! Et c'est son seul et unique intérêt!
L'hexa comme le décimal, n'interviennent que lorsqu'il s'agit d'afficher des informations et de les rendre plus lisibles pour l'être humain, autrement dit ces formats n'existent qu'à l'écran, au même titre qu'un texte ou une image, parce que l'ordinateur ne traite rien d'autre que des 0 et des 1!
Donc un fichier n'est qu'un gros tableau de bits!
Par contre selon le type de fichiers, il peut y avoir des alignements qu'il est souvent utile d'exploiter pour compresser: ainsi on trouve très classiquement des alignements sur un octet ou moins, qui va représenter la couleur primaire d'un pixel, un caractère dans un fichier texte...
Les formats de compression les plus simples exploitent généralement cet alignement, c'est le cas du RLE ou du LZW par exemple.
Donc les étapes pour compresser un fichier sont très simples finalement, on l'ouvre, on récupère l'ensemble de son contenu, on applique l'algo sur les données binaires brutes et on retient l'extension.
Ensuite il n'y a plus qu'à décompresser pour retrouver l'ensemble du volume du fichier d'origine, et lui remettre l'extension et voilà!
C'est pas plus compliqué que ça!
Il faut aussi prendre en compte le fait que la plupart des fichiers stockés sont déjà compressés, ce qui rend très difficile le fait de compresser davantage puisque l'information en est très "brouillée"!
Donc idéalement il faut partir d'un fichier non compressé, tel que le wav ou le bmp (en optant pour un bmp non compressé, c'est au choix), ou encore exe, ou bien il est nécessaire de décompresser le fichier via un codec interne avant de travailler sur les données réelles.
Evidemment, un format son ne se compresse pas de la même manière qu'un format image ou exécutable, ou bien avec des résultats très mitigés!
Il faut aussi s'attendre au fait qu'un algo de compression puisque apporter de l'embonpoint au ficher au lieu de le réduire, surtout en compression sans perte!
Ce sera sans doute le cas en appliquant du huffman sur un ficher jpg!
Bon courage!
gama kishi
Messages postés
20
Date d'inscription
dimanche 14 juillet 2013
Statut
Membre
Dernière intervention
10 août 2014
26 juil. 2014 à 12:23
26 juil. 2014 à 12:23
Merci ce un peu plus claire maintenant :O)
Je crois que je fonsait un peu tete baissee, mais maintenant je veux me reorienter parrapport ton expliquation.
encore merci et a+
Je crois que je fonsait un peu tete baissee, mais maintenant je veux me reorienter parrapport ton expliquation.
encore merci et a+
26 juil. 2014 à 11:01
à vrai dire je debute un project de compression de fichier.
Quand je dit fichier *.* je tout simplement voulu dire tout fichier(.exe image video text ...)
Pour être hônete je n ai pas encore un algorithm de compression, je suis entrain d apprendre un algorithm en c++ avec la methode huffman tout en l adaptant dans mon projet.
voici ce que je essayé de faire pour le moment:
1. Je un fichier .txt par exemple
2. Je l ouvre avec un editeur hexa,(avec Hex editor neo)
3. Supposons que j ai compressé le contenu qui est au format hexa que j ai obtenu.
4. Maintenant je souhaite la decompresser..... supposons que je l ai fais aussi.
5. Comment le restituer au format du fichier d origine (.txt).
je essayer de le réenregirtre avec l extension .txt ,mais le contenue d origine ne revien pas il reste que en hexa.
je assayer la meme chose avec un exe, juste l ouvrir en exa et le restituer en exe, il gagne en taille et ne s execute plus.
je essayé aussi avec un .jpg mais pareille.
alors je sais plus continuer avec mon projet car deja un fichier que je converti en hexa ne revien pas au fichier d origine.
Si tu peut m éclairer là dessu ça sera vraiment gentie...
Si par hasard ma façons de faire ne pas la bonne pour compresser et decompresser un fichier dit mois ce que je dois faire stp.
encore merci pour l aide