Bonjour  
Je suis novice en programmation c. Je souhaite, dans le cadre d'un travail de recherche à présenter, écrire un programme de cryptage par la méthode de vigenère. le plus de mon algorithme est qu'il devra prendre en compte les caractères accentués, les chiffres les espaces ainsi que les ponctuations de la langue française (à,é,è,ê,ç, ù,1,2,3,4,5,6,7,8,9,0).
j'ai pu écrire l'algorthme suivant mais je n'arrive pas a extraire le resultat du texte chiffré pour l'afficher a l'ecran. ce resultat se trouve en principe dans le tableau cod.
 
Ci dessous l'algorithme.
 

Je sollicite votre indulgence et espère avoir un retour assez rapidement  
Merci

Votre détermination de la nouvelle position n'est pas bonne, car la fonction "wcschr" renvoie un pointeur sur la position et, par construction (si le retour n'est pas nul) *Pos = Let et *PosLetCle = LetCle.
 
Pour la nouvelle position, vous ajoutez donc deux wchar et vous vous servez de la somme comme index dans le tableau Alpha, ce qui n'est pas correct.
 
Vous devriez utiliser une fonction qui renvoie le premier index du caractère dans la chaine (au pire vous l'écrivez vous-même, cela prend environ 30 secondes) et cela marchera mieux.
 
Par ailleurs, sauf erreur de ma part, vos allocations initiales de chaînes de type  "wchar_t Acoder []={}"  allouent un pointeur sur une zone de 1*sizeof(wchar_t) (pour mettre le 0 final) et faire des wscanf dessus ne peut que provoquer des choses douteuses en mémoire ... Allouez les à une taille "énorme" (1024 par exemple) et cela devrait éviter des soucis.

Bonjour
J'ai essayé d'apporter les modifications mais le code ne donne pas le resultat escompté. Ci dessous le code
 

pouvez vous me dire ce qui ne vas pas ?

Bonjour ! Sauf erreur de ma part, votre tableau Alpha ne fait que 34 caractères (les 26 lettres, plus l'espace, plus les codes 133, 130, 138, 136, 151, 135 et 147), et dans votre test, vous comparez les index à 40 ...
 
Pour PosCle, vous devriez démarrer à 0 et non pas à 1 (et recommencer à 0) et tester si PosCle est >= lgclef
 
Pourquoi ne pas tester dynamiquement la taille de ce tableau pour savoir si vous devez boucler ? Cela vous permettra de rajouter des caractères sans avoir à modifier le reste du code et, et c'est le plus important, cela assure que vous ne sortez pas du tableau.
 
Edit : Le fait qu'un caractère de la clé ou du message à chiffrer ne soit pas dans les lettres autorisées n'est pas géré (a priori, le code fait la même chose que si c'était un "a" ).

En plus des caractères accentué (à,é,è,ù,ô,ê) nous avon voulu aussi gérer les ponctuation (?.!,; ce qui emmenne le nombre d'élément du tableau à 40 caractères. pour la gestion des erreurs en cas de caractères non autorisés saisi, je n'ai pas encore pensé gérer cela. J'ai modifié le code en gérant dynamiquement le test sur la taille du tableau cependant mon codage de vigenere ne me retourne pas le resultat attendu.
Ci dessous l'algo corrigé
 

Re-bonjour  
 
Sauf erreur de ma part, il manque l'initialisation de PosCle. De plus, le test doit être if (NouvPos >= lgalpha), pour rester dans l'intervalle entre [0, longueurChaine-1].
 
Le reste parait bien, à première vue. Pour vérifier, si le résultat n'est toujours pas bon, faites afficher les chaines Cle et ACoder et postez le résultat ...
 
Bonne finalisation !

PosCle a été initialisé lors de sa déclaration à la ligne 10 par int PosCle =0;
 
L'affichage des chaînes donne le résultat suivant  
 
 Veuillez saisir la phrase à crypter:
bienvenue
 
 Entrez la cle de codage de la phrase:
test
la phrase codee est: f%xczwc3i
la phrase a chiffrer est: bienvenue
La cle de chiffrement est: test
 
La phrase codé n'est pas correct. En prenant le tableau définie dans Alpha et en appliquant les principe de vigenère, on devrai obtenir avec le mot "bienvenue" et la clé "test" le code suivant : umwçaiù:x

En effet, j'avais mal vu pour l'initialisation
 
Ensuite, je pense que deux problèmes se télescopent :  
 
 * Vous incrémentez PosCle avant toute utilisation, ce qui fait que vous démarrez au premier caractère "e" au lieu d'utiliser "t" pour le décalage du premier caractère => le "u" que vous deviez obtenir devient un "f", ce qui paraît correct => Soit vous initialisez PosCle à -1 (bof ...), soit vous décalez votre incrémentation après la ligne "LetCle = Cle[PosCle]; "
 
 * Je ne suis pas du tout habitué aux wchar, mais l'impression que cela me donne est que le %c133 n'est pas remplacé dans la définition de la variable Alpha (ce qui paraît normal ...). Le mieux serait de déclarer cette variable comme les autres wchar_t Alpha[200]; et effectuer un wsprintf (ou équivalent) pour la remplir, je pense que cela marcherait.
 
Vous pouvez rapidement tester le second point en limitant le jeu de caractères dans Alpha aux caractères "normaux" et voir si le résultat est correct.

Bonjour  
Merci pour votre aide précieuse cela m'a permis de corriger le code et j'obtient maintenant le résultat escompté. j'ai remplacé les valeur %133, % 131 .... par leur équivalent en hexadecimal en les definissant comme x85 x83 .....
Cependant un problème subsiste toujours. lorsque je décide de rentré ma phrase à codé en y incluant des espaces la c'est le comble le programme ne fonctionne plus comme cela devrait. un exemple :
en voulant codé le texte : bienvenue au pays avec la clé test, j'ai le résultat suivant
la phrase codee est: bèeôvynae
la phrase a chiffrer est: bienvenue
La cle de chiffrement est: au
 
le programme considère le mot après l'espace comme la clé, ignore le troisième mot (pays) et ne demande même pas de saisir la clé et me retourne le résultat mentionné ci dessus.
 
Comment pourrais je corriger le code pour prendre en compte l'espace. J'ai essayé d'ajouter dans la déclaration d'Alpha le code hexa d'espace (x20) mais cela n'a rien changé
 
Ci dessous le code  
 

Bonjour !  
 
C'est le défaut avec scanf quand on lui passe une chaîne, il s'arrête au premier espace ... Je vous conseille de faire un fgets (ou son équivalent wchar) pour pouvoir saisir une valeur contenant des espaces (attention, il vous faudra peut-être enlever le retour chariot final).

ok je vois et je comprend mieux l'usage de scanf. j'ai modifié le programme mais une dernière erreur persiste. Après exécution, je remarque que le premier caractère de la clé est omis lors du processus de cryptage. J'obtient alors le resultat suivant  
 
 
 ***** Cryptage et Decryptage de Vigenere *****
 
 Merci de faire un choix
 
 [1] pour le cryptage
 [2] pour le decryptage
1
Veuillez saisir la phrase à crypter:bienvenue à esgis
Entrez la cle de codage de la phrase:test
la phrase codee est: fàxr:xr;x?eji.zm.
la phrase a chiffrer est: bienvenue à esgis
La cle de chiffrement est: est
 
 
Il prend comme clé de chiffrement 'est' alors que j'ai rentré 'test'
 
ci dessous le programme que j'ai exécuté
 

Pourquoi faites-vous un fgetc(stdin) avant le fgetws ? C'est sans doute lui qui "mange" le premier caractère de la saisie (donc de la clé).

Merci pour votre précieuse aide . Le code fonctionne à présent . ci dessous le code .
 

Non, j'ai recompilé et testé sur ma machine, et il ne fonctionne pas correctement dans mon environnement.
Il y a plusieurs raisons manifestes:
1- C'est un programme en mode console. La console que vous utilisez est sous quel système? (chez moi sous Windoxs XP US, c'est la page de code DOS 437)
    Si c'est un programme en mode console sous Windows, (ce que me laisse penser votre rewind(stdin) qui n'a aucune assurance de fonctionner dans d'autres environnements) il n'y a aucune raison particulière pour que l'input soit en wide-char (l'input de ma console est en char).
   Bon, avec le compilateur de Microsoft, et un appel à _setmode, on peut y remédier (si tant est que la fenêtre console a les fontes Lucida activées, ce qui n'est pas le défaut).
2- Le plus gros problème est dans les algos de cryptage/décryptage, qui dépendent de search, laquelle renvoie une valeur pour tout caractère, même s'il ne figure pas dans l'alphabet de codage (par exemple les majuscules, avec votre alphabet).
    Pour corriger cela, faire renvoyer -1 à search, et dans vos algos, quand on tombe sur cette valeur de -1, mette la lettre en entrée identique à celle de sortie, tout en avançant la clé.
Soit quelque chose comme ceci dans l'algo de cryptage:

 
Il y a d'autres problèmes, mais mineurs.
 
A+,

Vous devriez tester les deux valeurs de retour, gilou, car avec ce code là, le piège à bug est armé !  
 
Cas : pos = -1 (caractère non conforme entré dans la clé)
         pos1 = 0 (caractère 'a' dans le message à chiffrer)
 
Pas la peine de vous faire un dessin pour la suite (même si on ne fera que lire au mauvais endroit dans la pile, ce qui ne devrait pas être trop méchant ...)
 
Pour être tout à fait honnête, j'avais vu cette source de problème dans les premières version du code, mais comme le code fourni ne présentait pas de risque (retour 0 si caractère inconnu, comme pour 'a'), j'avais laissé filer

A priori avec une définition de search comme:

je ne pense pas qu'il y ait de problème.
De toute façon, l'emploi de wcschr et d'une différence de pointeurs me semble plus adaptée que cette fonction ad-hoc.
 

Certes, mais on ne peut plus décoder correctement, puisqu'on tout caractère hors de l'alphabet va alors être décodé comme un a, puisqu'il y est identifié au moment du codage.
A+,

Le problème potentiel vient du fait que l'on peut avoir pos1=0 et pos = -1, le problème ne venant pas de la fonction search (qui parait très correcte) mais du fait que l'ensemble dans lequel on recherche l'index d'un caractère de la clé dans un sous-ensemble (la chaîne Alpha) et que l'opérateur peut très bien saisir "cle0" comme clé (les chiffres ne sont pas gérés dans le code fourni).
 
Pour le deuxième point, entièrement d'accord avec vous

Pour le premier point, tout à fait.
Mais il semblerait logique que la cohérence de la clé vis à vis de l'alphabet (voire même d'une partie de cet alphabet) soit exigée et vérifiée avant de commencer le codage (sinon, on peut toujours tomber sur le cas ou la clé n'est constituée que de caractères hors de l'alphabet, cas pour lequel je ne vois pas de solution de secours applicable).
A+,