CRYPTAGE ET COMPRESSION PAR PLAGE
John Dogget
Messages postés
384
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
7 mars 2007 à 23:35
John Dogget Messages postés 384 Date d'inscription vendredi 18 juin 2004 Statut Membre Dernière intervention 7 mai 2009 - 8 mars 2007 à 19:59
John Dogget Messages postés 384 Date d'inscription vendredi 18 juin 2004 Statut Membre Dernière intervention 7 mai 2009 - 8 mars 2007 à 19:59
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/41780-cryptage-et-compression-par-plage
https://codes-sources.commentcamarche.net/source/41780-cryptage-et-compression-par-plage
8 mars 2007 à 19:59
Rien à voir avec ta source donc oO
8 mars 2007 à 19:48
1- tous les nombres sont codés sur 7 bits
2- pour decrypter le fichier il faut multiplie chaque nombre par 2 .
exemple A=(200,150,121,100,80,150)coute 6*8bits=48bits
B=(100,75,60,50,40,75) coute6*7bits=42 bits
l'ensemble B est compressé et decompressable par simple multiplication par 2,mais il faut crier un decodeur qui fait la lecture du 7 bits puis la multiplication par deux seulement,
ça est le principe de l'ondelette de Haar,
la differance du couleur entre 120 et 121 est egligeable par ce que on un mixage de R et G et B et le pixel est tres petit
8 mars 2007 à 19:37
@John : laisse tomber, c'est pas la peine de discuter
8 mars 2007 à 19:19
Et puis, pour compresser des images, les formats modernes font vraiment mieux que toi, sans pour autant abîmer en apparence l'image.
8 mars 2007 à 19:02
exemple RGB=(200,150,121) representable sur 8bits*3=24 bits, si l'on compresse par division sur 2 on a (100,75,60) representable sur 7bits*3=21bits a condition que l'on connais a prioré qu'il faut multiplie par deux ,on a gagne 3 bits mais on a perdu l'exactutide du couleur blue par ce que 60*2=120 ,l'influence de perte est negligeage devant le gain de 3 bits ,
si la taille du fichier = 1 mega on gangne 1/8 ,
8 mars 2007 à 17:49
8 mars 2007 à 16:40
Pour la chaine éèî
c'est l'impossible de l'impossible de trouver cette chaine mais je vous rappele qu'il existe la compression irreversible avec perte dans la norme JPEG2000 et ce n'est pas obligatoire de recuperer les memes caractères compressés par exemple dans les couleurs on a une degradation de couleur , la source fait la compression des octets (code ascii) mais on peut la changer pour compresser le UTF-8 (liser les word du stream au lieu d'octets)
Finalement , Francky assai d'encourager les autre au moins fait des salutations ou remerciements dans la fin des comentaires ,
8 mars 2007 à 09:55
En html si jécris éèî
tu es sur que le source n'aura pas de caractères relatifs à la base ASCII ETENDUE ?
Un fichier texte ou html n'est jamais encodé sous cet algorithme : on l'encode en Base 64, en QP, en 'UTF-8', en binaire, en 7-bits, en 8-bits, en zip, en rar mais surement en ton truc.
Si tu réfléchissais un petit peu avant de balancer n'importe quoi comme source, ca t'éviterait d'etre obligé de dire un tissu de bétises.
Mihoubi une fois de plus tu as posté n'importe quoi sans réfléchir (il est grand temps que tu arretes) : tu viens d'en faire la démonstration singlante.
8 mars 2007 à 08:50
toujours supprime un ou deux ou trois ... bit a gauche par exemple :
01011010 devient 1011010 et apres decompression devient 01011010
ça est la compression reversible ,
mais si le debut de caractère est un comme (10101010) ici on parle du compression irreversible , le caractère devient (00101010) ,
l'interet de de la source est: notant que tous les caractères des fichiers textes sont inferieure à 127 et les HTML aussi souvent , on peut representer sur 7 bit seulement
8 mars 2007 à 07:21
alors, vas sur codyx, recherche les methodes :
Données vers binaire (chaine)
Binaire (chaine) vers donnée (binaire vers decimale par exemple)
ça te permettras de remplacer tes deux methodes "bidule machin" par des methodes plus performantes, fiables et souple.
par contre si tu veux te lancer dans plus costaud : Huffman, Burrows-Wheeler
8 mars 2007 à 01:17
Au fait Francky , pas perd l'nord voit pas Florenth ici mais bien John Dogget ( et oui ils ont le m avatar ! ;) )
Sinon ca peut franchement etre assez marrant comme source ... (enfin moi je trouve !)
Ciao
8 mars 2007 à 00:34
8 mars 2007 à 00:32
"Si la plage est inferieur a 64 on peut les representer
sur 6 bits" : a bon ca existe une table de 64 caractères ? ca correspond à quel format.
Je confirme les propos de Florenth : on perd des infos meme en utilisant une table ASCII classique (donc les 127 premières caractères).
Evite de mettre de l'ASM si tu peux t'en passer : on est sur Delphifr. Ce n'est pas la première fois.
Tu veux un conseil / un critique : Fais un projet intélligent, utile, correspondant à un vrai projet, plutot que de poster des trucs que tu fais en 5 min et qui n'ont aucun intéret
7 mars 2007 à 23:35
J'ai fais un test rapide avec le fichier texte contenu dans le zip, ça marche pas top :/
Texte de départ -> Size=992
Compression + cryptage -> Size=880
Décryptage et décompression -> Size=999
Le texte d'origine est perdu, certains caractères ne sont pas reproduit à l'identique on dirait.
Les accents par exemple sont perdu, le caractère "é" est reproduit en "C)".
Et aussi il aurait été sympa de coder la partie assembleur de ta source en Delphi.