polytech-projects / huffman Goto Github PK

S'assurer que l'enregistrement se fait toujours de la même manière (au niveau de la manipulation des bits) quelque soit le type de processeur.

Au moins vous avez mis dans le Wiki les éléments de réflexion actuels et vous avez bien travaillé ! C'est en bonne voie.

• je pense qu'il faut que vous fassiez d'autres exemples vous-mêmes à la main pour vous assurer de la bonne compréhension

• pour la fin de fichier, c'est une solution mais ce n'est pas la bonne car dans ce cas, vous devrez coder la taille du fichier sur un nombre de bits donnés, ce qui limitera la taille de ce dernier et vous empêchera également de coder un flot à la volée

  • La bonne solution consiste à créer un caractère fin de fichier VIRTUEL
  • Votre arbre est initialisé avec ce caractère fin de fichier virtuel de points 1 + le caractère inconnu du poids 0
  • Quand on a fini la compression, on émet le code de ce caractère -> on peut ensuite faire librement du bourrage
    Mais c'est bien que vous ayez décelé ce problème.

• Pour l'écriture bit à bit, effectivement, il faut bien un buffer

  • Par contre, vous pouvez prendre un buffer plus grand qu'un unsigned char
  • Cela vous laisse plus libre d'ajouter des bits (éventuellement plus d'un), puis de vérifier s'il y a plus de 8 bits en buffer -> écriture
  • Et du coup, le point ci-dessus répond au problème du bourrage non ?

• Effectivement, pas besoin de buffer pour lire le fichier ...

• Pour la représentation du caractère "non utilisé", effectivement, en fait, il faut "étendre le table ASCII" d'une certaine manière -> donc ajouter des bits -> donc vous pouvez ajouter simplement un FLAG short int dans vos feuilles indiquant : caractère ASCII / caractères supplémentaires.

  • Et du coup, vous aurez à la fois le caractère "non rencontré" et "fin de fichier virtuel".
  • D'ailleurs, c'est pratique de définir une union {ASCII, NON_RENCONTRE, EOF_VIRT} .... au moins les noms sont parlants

• Pour lire le fichier compressé, vous lisez octet par octet dans un buffer. Et c'est dans ce buffer que vous "regardez les bits" les uns après les autres

  • quand le buffer a été "consommé", on recharge ...
  • la décompression est totalement symétrique de la compression et repose en fait sur la même fonction de mise à jour de l'arbre
    ** Je vous conseille de faire un exemple complet en compression / décompression pour être bien sûrs de vous **

Pour moi, votre réflexion est bien avancée, feu vert pour commencer le codage (et n'hésitez pas si vous avez des questions : vous détaillez dans le Wiki et m'alertez par mail).