cryptage (simple ...)

Question

SISI231

Bonjour ! ...
J'aurais une petite question sur l'encodage ...
J'ai vu sur un site : je ne me souviens plus duquel : peut-être
celui-là ... une méthode simple d'encodage, cetes non suffisante pour des cryptages professionnels mais suffisant pour mon programme qui consistait à remplacer chaque caractère par chr (ord(caractère)-64 (par exemple ...))por crypter et par chr(ord(caractère)+64) pour décrypter ...
Seulement je l'ai essayé et au décryptage je me retrouve avec une chaîne dont certains morceaux correspondent avec la chaîne de départ et d'autres nons : je voudrais savoir pourquoi, j'ai personnellement queques hypothèses :
- peut-être cela se passe-t'il quand le nombre (qui est entre les parenthèses de chr) dépasse 255 ou est négatif ...
- il y a un caractère nul à l'encodage ou au décodage qui fausse tout (peu probable ...) ...
- les caractères "rectangle" (autrement dits qui ne sont pas définis) faussent tout (peu probable ...) ...
-ce sont les caractères #10 et #13 qui faussent tout (peu probable) ...
Voilà ... sinon je finirais en précisant que le texte qui a servit d'essai a été copié-collé de l'aide de delphi (c'est un texte ne contenant que des caractères standarts ...) ...

Merci de me répondre ... :)

cs_Bestiol · Answer

Euh... je suis pas sûr de répondre correctement... mais c'est peut-être ça :

Tu dis que le principe est, je cite, "remplacer chaque caractère par chr (ord(caractère)-64)pour crypter et par chr(ord(caractère)+64) pour décrypter "

J'ai donc fait un code correspondant à cela... Le seul problème qui est apparu, c'est avec les lettres majuscules "M" et "J"... A chaque fois est respectivement ajouté un "J" ou un "M" !

Je pense avoir trouvé d'où vient ton problème... (j'ai utilisé des TMemo, ce serait peut-être différent dans des RichEdit)
Si tu regardes les valeurs ASCII associées à  "M" et à "J", tu verras que c'est 77 et 74... Or 77 - 64 13 et 74 - 64 10 !
Donc, à chaque fois qu'un "M" ou un "J" sera codé, le caractère obtenu sera considéré comme un retour chariot ou un saut de ligne : #13 ou #10... Mais, dans un composant comme le TMemo, chaque appui sur [entrée], pour sauter une ligne, est caractérisé par l'assemblage #13#10... Je pense en fait que tes caractères, une fois codés, sont considérés comme un appui sur [entrée], et un #13 ou un #10 est automatiquement ajouté... D'où le "J" ou le "M" ajouté au décodage, puisque la lecture se fait caractère par caractère !

Autre "erreur" : l'arobase... Son code ASCII est 64... Pas besoin d'être un génie pour comprendre que 64 - 64 font... 0 !! Le caractère codé sera donc le caractère #0, et cela coupera toute la chaine dès que celui-ci sera interprété pour le décodage !

Il me semble que ce sont les 3 seules anomalies que j'ai trouvées, mais j'en ai peut-être oublié !!

La solution que je te propose, c'est de changer de codage !!
Ce serait plus simple, je pense... Une méthode par XOR n'est pas trop difficile à mettre en oeuvre !

Un exemple serait par exemple de convertir la valeur ASCII de chaque caractère en hexadécimal... 
En effet, un caractère a normalement une valeur comprise entre 0 et 255, soit entre $00 et $FF, donc il est possible de coder chaque caractère toujours sur deux... le texte sera plus long, mais il te suffit dans une boucle avec un pas de deux, de lire le caractère i et (i + 1), ce qui te donnera une valeur hexadécimale à convertir pour le décodage...
Avec un petit xor, et ton codage simple est en oeuvre !

Voilà voilà !!
Bonne prog' !
[mailto:bestiol@cario.fr Bestiol.]
PS: et si je n'ai pas été clair, il te suffit de réclamer des explications !

cs_Bestiol · Answer

Je t'ai fait un petit exemple pour implémenter le codage dont je t'ai parlé... Si ça t'intéresse, je peux te l'envoyer par mail !

Bonne prog' !
[mailto:bestiol@cario.fr Bestiol.]

Cryptage (simple ...)

2 réponses

Votre réponse

Discussions similaires