Discussion :

[dranakan]

Hello,

Je désire compresser une courte chaîne d'information (pour générer un code-barres de petite taille). En m'aidant de java.util.zip, je m'aperçois que la chaine compressée est plus grande que la taille originale (ce qui est normale avec les données que je donne et l'algorithme utilisé).

Voici un exemple de chaîne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<S>fi=3452355&re=aadjek&ty=df&nb=1000343</S>

Y-t-il un autre algorithme/API à utiliser pour réduire la taille de cette chaîne ?

Je me suis aider de ce code pour effectuer la compression : http://softwaredevscott.spaces.live....F3B7!299.entry

Merci bien.

[tchize_]

ce n'est pas possible car
-> pour un code barre, tu est limité dans le nombre d'octets utilisable (obligé de prendre de l'ascii en général
-> Une courte chaine ne présente aucune redondance pouvant servir à la compression

[dranakan]

Merci bien

[thelvin]

Bah, au fond... Si le <S> de début et le </S> de fin sont toujours là, il est inutile de les mettre dans la forme compressée. Tu n'as qu'à les remettre à la décompression.

Si les paramètres sont toujours fi, re, ty et nb, dans cet ordre, tu peux virer cette information.

Ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

3452355&aadjek&df&1000343

Les nombres peuvent être écrits en hexadécimal ou en base64 pour gagner de la place.

[adiGuba]

Salut,


Si tes différents champs ont une limite de taille bien précise, on pourrait même aller plus loin dans la proposition de thelvin en supprimant les & et en mettant chaque champs sur un nombre fixe de caractère.

a++

[Jimmy_]

Oui c'est possible il faut utiliser une compression statistique de Huffman avec une table fixe calculée une fois pour toute. Ce qui te permet de la stocker sans la faire transiter.
Les caractères revenant le plus souvent sont compressés sur quelques bits (3 ou 4), les autres sur plus.

Zip sauve un dictionnaire pour décompresser ce qui le rend inutile pour des fichiers petits.

[tchize_]

jimmy: tu va te retrouver avec du pur binaire, autrement dit une information qu'on ne peux sotkcer dans un code barre. A l'arrivée il devra convertir ses nombres 8 bits en un ensemble de données acceptable par le truchement, par exemple, de base64, ce qui au final refera grandir l'élément de 1/3 de la taille compressée. Vu le style de donnée, je suis dubitatif quand à
-> la présence de données récurrentes
-> l'utilité de tout ce bordel pour peut être gagner 5%