Compression de texte pour uploadRésolu

Question

Bonjour à tous,

je suis en train de développer une petite appli web qui stock dans un tableau les choix de l'utilisateur. Au final, je traduit sous forme de string le tableau en supprimant les null et autre undefined. Voici ce que donne le string :

1-1-1-1;1-1-2-1;1-1-3-1;1-1-4-1;1-1-5-1;1-1-6-1;1-1-7-1;1-1-8-1;1-1-9-1;1-2-1-1;1-2-2-1;1-2-3-1;1-2-4-1;1-2-5-1;1-2-6-1;1-2-7-1;1-2-8-1;1-2-9-1;1-3-1-1;1-3-2-1;1-3-3-1;1-3-4-1;1-3-5-1;1-3-6-1;1-3-7-1;1-3-8-1;1-3-9-1;1-4-1-1;1-4-2-1;1-4-3-1;1-4-4-1;1-4-5-1;1-4-6-1;1-4-7-1;

L'idée est d'enregistrer ce string sur le serveur, via ajax par exemple.
Le problème, c'est que le string peut potentiellement contenir plusieurs millions de signe. Un test m'en a donné un fichier texte de 8Mo au total.

Alors, je me suis dit que j'allais découper le string en plusieurs morceau pour envois séparés. Mais cela ne réduit pas le poids global...

Alors je me suis dit que j'allais chercher du côté de LZW. J'ai trouvé ces 2 scripts, similaire mais donnant une compression un tout petit peu différente... première interrogation...
Tapez le texte de l'url ici.
Tapez le texte de l'url ici.

Le problème, c'est que je doute de la compression généré par ces scripts.


Mon objectif est :
1 - compression js client
2 - envoi serveur
3 - recup php, décompression, et traitement.

l'utilisateur se reconnecte et veut continuer son travail :

4 - Compression PHP sur serveur
5 - Décompression js sur client

Bien sur, l'étape 4 n'est pas forcément nécessaire puisque je peux conserver le fichier de l'étape 1 tel quel.
Mais impossible de passer l'étape 3, essentiel car je ne peux traiter les données sur le serveur !

Quelqu'un aurait-il déjà abordé ce genre de chose et aurait une piste à m'indiquer ?
Bien sur je ne suis pas bloqué sur LZW, mais ça me semblait pas mal. Si vous avez d'autre piste, je prends !

Merci à tous

niamor36 · Accepted Answer

J'ai finalement résolu mon problème de compression.

Pour info les 2 sources citées dans le post initial sont fonctionnelles en apparence mais elle sont incorrectes. Le dictionnaire généré pour la compression LZW est faux (le tableau dico contient en réalité 10 entrées au lieu des 256 attendus). En partie du à une mauvaise gestion du tableau associatif javascript et au bug de FromCharCode. 
Comme la compression et la décompression utilise le même dictionnaire erroné, on n'y voit que du feu. Mais dès qu'on essaie de traduire l'algo en php ou autre, impossible de d'obtenir une compression identique, et bien sur encore moins de passer de js à php ou inversement...
Le dictionnaire généré en php est correct car les tableau associatif sont mieux gérés et pas de bug avec chr ou ord

Plus tôt que de partir d'une source js, je suis partie d'un très bon script php (mille mercis à à l'auteur Jakub Vrana):
http://code.google.com/p/php-lzw/
La traduction en javscript est assez aisée.

Le renversement du tableau pour créer le tableau associatif et le passage par l'affectation binaire est bien plus stable.

J'obtiens un excellent ratio de compression d'autant que mon string est très séquencé.

ex : 6000 signes non compressés donnent 1500 signes compressés
donc un poids divisé par environ 3 à 4.
le temps d'encodag est très rapide sur aussi peu de signes, quasi instantané.
Un peu plus rapide au décodage. 

J'y gagne en rapidité de transfert, en bande passante, et en espace de stockage tant sur le serveur que sur la bdd client.

Au poil !

Bul3 · Answer

Bonjour,
>>le string peut potentiellement contenir plusieurs 
>>millions de signe
oulah ???? je dirais erreur de conception.
je verrais les choses autrement !
plusieurs échanges avec le serveur et
mémorisations intermédiaires par exemple (?)
Cordialement	[mon Site]	[M'écrire]	Bul

Bul3 · Answer

ne serait-ce que pour les cas d'incidents !
imaginez un internaute qui a saisi pendant
des heures ( pour des millions de carcatères
c'est sûrement nécessaire ) et que ça plante
pour une raison quelconque ( coupure courant 
ou autres ... )
avec des échanges intermédiaires on pourrait
lui permettre de reprendre, au moins

niamor36 · Answer

Merci de ta réponse Bul3.
Je crois que cela mérite quelques précisions :

- Oui effectivement, 8 millions de signe demandent un peu de temps pour être générés. Mais pas tant qu'on le croit. Même si cela se produira rarement, c'est un cas extrême, j'essais juste d'envisager tout les cas de figure...

- J'ai effectivement envisagé des enregistrements intermédiaires. Mais c'est une solution intermédiaire qui ne suffit pas car :
&#8226; Effectuer des envoi de modification uniquement ne fait que déplacer le problème en augmentant la charge au niveau du serveur. La position des blocs "n-n-n-n" les un par rapport aux autres a sont importance (pour le traitement php sur le serveur). Au php de faire les insertions...

&#8226; Quand bien même je gèrerais les modifications en petites sauvegardes intermédiaires, il n'en reste pas moins que l'utilisateur doit à la connection charger l'intégralité du fichier...

- le string est déjà sauvegardé en local via une bdd créée à la volée en local (html5). L'appli fonctionne offline. Mais à la reconnection, il se peut que la synchro soit aussi très lourde...

Bref, tu as raison, un flux permanent de petite upload des modification réduit un peu le problème, mais pas complètement ! 

D'ou mon besoin de compression quoiqu'il en soit.
Mais là c'est un territoire inconnu pour moi !!

N'hésitez pas si vous avez un petite piste...

A+

Bul3 · Answer

mettons 1 million de caractères
avec une saisie toute les 1/2 seconde
vous avez calculé le temps de saisie nécessaire ? 
si je ne fais pas d'erreurs de calcul !
je ne voudrais pas insister, mais il 
y a quelque chose qui m'échappe !

niamor36 · Answer

Une appli web de construction vectoriel.
Je crée un objet dynamiquement, avec différents paramètres notamment de positionnement, et je l'ajoute au dom. 
ex : 



Dans le même temps, je l'enregistre dans un tableau multi dimension avec les paramètres.

A l'enregistrement, je convertis les objets présent dans le tableau en string, avec séparateur des valeurs.

Un objet correspond à entre 8 et 17 caractères dans le string

Mon certain outils de l'appli permet de générer environ 12 objet/seconde (dépend du navigateur et de l'ordi of course). Voir plus (copier-coller).

donc 12*12 (moyenne basse) = 144 caractère par seconde.

pour 1 million, 6944 secondes environ.
soit 115 minutes
soit 2h 

disons 3/4 heures pour être très large. Nous avons nos 1 millions de caractères soit aux alentours de 1Mo à transférer.

C'est finalement pas si long... d'autant que l'utilisateur peut sauvegarder et y revenir plus tard.

augustingdlr · Answer

Mon problème n'est pas aussi lourd que le tien, mais j'ai également besoin pour mon back-office de compresser une chaine côté client.

Aurais-tu la source js de ton adaptation du script php de Jakub Vrana ?

Merci d'avance,
Gus.

niamor36 · Answer

Salut Gus,

Je m'étais promis d'en faire une source, merci de me le rappeler... 

C'est chose faite, peut-être un peu rapidement, mais je pense que ce sera déjà utile :

http://www.javascriptfr.com/codes/COMPRESSION-TEXTE-COTE-CLIENT-JS-VIA-ALGORYTHME-LZW_51326.aspx

A+R.

Compression de texte pour upload

8 réponses

Votre réponse

Discussions similaires