Transformer ASCII en Binaire

Bonjour :D

Je cherche une methode de transformer du texte en format binaire, en fait pour créer un format de fichiers plus rapide à charger, et il sera aussi moins lourd en taille je crois?

Par example le format .3ds de 3DSmax il est en binaire? Je voudrait pouvoir exporter mon modele ASCII dans le meme style.

Est ce possible avec string?

Je cherche des liens ou un tutoriel, meme un examples ca serait parfait :)

Merci ! :D

Un fichier, c'est forcement binaire (une suite d'octets).
Ce que tu veux, je suppose, c'est compresser du texte.
Regarde du côté de la compression d'Huffman ou de l'algorithme LZW.

Citation:

---

Envoyé par Sylvain Togni

Un fichier, c'est forcement binaire (une suite d'octets).

---

Si tu veux dire que tout, en informatique, n'est que bit, on est d'accord...

Citation:

---

Ce que tu veux, je suppose, c'est compresser du texte.
Regarde du côté de la compression d'Huffman ou de l'algorithme LZW.

---

Pas forcément...
Il existe un distingo très clair enre le format "texte" (tout est écrit sous forme de caractères) et le format binaire (les valeurs écrites utilisent un nomre de bit correspondant à sizeof(type)*(nombre de bit caractere) )

C'est, par exemple, le cas pour les fichiers obj/o/a/dll et binaire exécutables (évidemment), mais on peut très bien décider d'écrire en binaire plutot qu'en texte ;)

Happy==>Sauf erreur, c'est au moment où tu ouvre ton ofstream (ou ton ifstream pour la lecture) qu'il faut décider s'il est ouvert en binaire ou en "texte" (par défaut, c'est en texte)

Cela ressemble à

Code:

---

1 2 3 4 5 6

string nom;//nom du fichier //pour l'écriture ofstream ofs(nom.c_str(),ios::inary); //et pour la lecture ifstream isf(nom.c_str(),ios::inary);

---

Mais il faut absolument veiller à ce que les différents types que tu utilises soient identiques selon l'architecture du PC (entiers à 16/32/+:question: bits, ...)

Ceci dit, il me semble que boost::serialization permet également l'utilisation de fichiers binaires...

Il pourrait sembler intéressant d'y jeter un oeil, et ce, d'autant plus que tu pars visiblement sur un projet important: entre boost::filesystem, boost::serialisation et sans doute d'autres, tu gageras sans doute pas mal de temps à utiliser boost qu'à devoir "réinventer la roue" pour une série de choses ;)

Citation:

---

Envoyé par koala01

Pas forcément...
Il existe un distingo très clair enre le format "texte" (tout est écrit sous forme de caractères) et le format binaire (les valeurs écrites utilisent un nomre de bit correspondant à sizeof(type)*(nombre de bit caractere) )

C'est, par exemple, le cas pour les fichiers obj/o/a/dll et binaire exécutables (évidemment), mais on peut très bien décider d'écrire en binaire plutot qu'en texte ;)

---

Il y a de la confusion dans ce que tu ecris. Je ne sais pas si c'est incorrect ou simplement confu. Je vais repondre directement a Happy.

Citation:

---

Happy==>Sauf erreur, c'est au moment où tu ouvre ton ofstream (ou ton ifstream pour la lecture) qu'il faut décider s'il est ouvert en binaire ou en "texte" (par défaut, c'est en texte)

Cela ressemble à

Code:

---

1 2 3 4 5 6

string nom;//nom du fichier //pour l'écriture ofstream ofs(nom.c_str(),ios::inary); //et pour la lecture ifstream isf(nom.c_str(),ios::inary);

---

Mais il faut absolument veiller à ce que les différents types que tu utilises soient identiques selon l'architecture du PC (entiers à 16/32/+:question: bits, ...)

---

Les stream ouverts en binary n'ont strictement rien a voir avec ca. Ca ne change que des details (convention pour les fins de ligne par exemple).

Merci, je comprends :D
Pour boos::serialization c'est assez interessant aussi je m'en vais tester les 2 solutions 8-)
Merci encore! ;)

Je vais donc essayer d'etre moins confus:

Dans le sens où "tout n'est que binaire"(AKA: il n'existe que deux état pour les valeurs de base: le courent passe, ou il ne passe pas) dans un ordinateur, on peut, effectivement, estimer que meme un fichier texte codé en ASCII est... un fichier qui contient du binaire (en ASCII, les informations sont "simplement" regroupées par 8 ;))

Mais le distingo est fait au point de vue des fichiers par la manière d'écrire (et de récupérer) les informations dans le fichier (un peu à la manière de ce qui se fait en C avec fopen("fichier","r") ou fopen("fichier","rb") )

Quand on décide d'enregistrer en "mode texte", meme les entiers/reels/doubles utilisent des caractères pour etre enregistrés (ce n'est pas la valeur 0x00000001 qui est écrite, mais le caractère "1")

En binaire, quand on décide d'enregistrer un caractère, on enregistre la "taille utile d'un caractère" (généralement 8 bits), mais, pour un entier, un double ou un réel, on enregistrera la taille utile pour le type envisagé (qui correspondra, de manière générale, à sizeof(type)* taille utile du caractère)...

C'est ce que l'on rencontre dans tous les fichiers "binaires" dont font, entre autres, partie les fichiers créés lors de la compilation (du fichier objet (obj,o en fonction du compilateur) à l'exécutable "fini"...

Le problème qui se pose (ou du moins, qui se posait en C) est que, si à la création d'un fichier, tu utilise comme taille pour un entier de 16 bits (par exemple avec l'exécutable compilé avec l'antique BC31), et que tu utilises à la lecture une taille pour un entier de 32, comme n'importe quel exécutable compilé de nos jours (je suis d'accord, cela n'arrive qu'en cas de recompilation dans un autre environnement), tu essayera de lire... l'équivalent de deux entiers en une seule fois...

Est-ce que cette explication te parrait plus juste/moins confuse :question:

La difference entre fopen("fichier","r") ou fopen("fichier","rb") ) et la meme que la difference entre utiliser binary ou pas avec les IOStreams. Le fait que ce que le C et le C++ appelle des fichiers binaires n'a que peu de rapport avec ce qu'on entends par fichiers binaires habituellement est d'ailleurs la source de confusion principale dans ce que tu ecris.