Salut,
 
J'ai un souci sur l'un de mes projets. Je stocke dans une base de données Oracle des mots de passe chiffrés avec une procédure stockée livrée en natif par Oracle (Procédure DESEncrypt/DESDecrypt pour ceux qui connaissent).
 
Lorsque j'exécute mon code depuis mon poste de développement sous Windows, une chaîne "toto" est chiffrée en une chaîne A. Mais l'exécution du même code depuis un serveur AIX avec "toto" en entrée me donne une chaîne B.
 
J'ai placé des logs dans tous les sens, les paramètres de la procédure stockés sont identiques (chaîne à chiffrer et clé de chiffrage) que l'on soit sous WIN ou AIX mais le résultat est différent. (J'ai comparé les octets chaque caractère des paramètres...)
 
Je pense qu'il doit s'agir d'un problème d'encodage de caractères mais je n'ai trouvé aucune méthode à utiliser pour préciser/forcer celui-ci. De plus, le driver JDBC Oracle (thin) est censé effectuer la conversion des paramètres vers le jeu de caractères de la DB de manière transparente.
 
 
Déjà eu ce genre de problème ? Est-ce-que quelqu'un aurait une piste vers où chercher ?
 
Merci

sur "toto" je doute que tu ais des incompatibilités d'encoding (à moins d'attaquer du bizarre), à mon avis, cherche ailleur.

C'est ce que je me disais aussi mais avec des chaînes uniquement alphanumériques, mon problème survient

hum, à moins que utf16 ...
tu peux inspecter la chaine en java elle est bonne ?

c'est quoi ce titre

Ca ne te dit rien ? A moi non plus.

 
J'en déduis donc que ça ne te dit rien comme problème...
 
Sacré --  

ben tu crois que j'ai lu? tu pollues le visitage de forum, mec

En encryptant deux fois de suite ta chaine sur la meme machine c'est vraiment la meme qui resort a chaque fois?
 

Oui, le cryptage est répétable et redonne à chaque fois le même résultat. De plus, le décryptage fonctionne. C'est juste que le résultat chiffré diffère selon la plate-forme d'exécution.
 
C'est même pire que ça puisque sous WIN je peux avoir un truc chiffré (une fois encodé en base 64) qui donne:
 
pILm5tI=
 
et sous AIX:
 
mILf5gY=
 
(J'ai vérifié, l'encodage 64 fonctionne sur les 2 plate-formes)
 
Il y a de grosses ressemblances entre les 2 chaînes, tous les caractères ne diffèrent pas. C'est ce qui m'avait fait dire que l'encodage de char était en jeu pourtant les String encodés sont tout ce qu'il y a de + simple.
 
C'est bizzarre...

 
Alors ne pollues pas mon topic, stp

Faut faire gaffe, même une chaîne comme 'toto' qui ne contient aucun caratère bizarre est codée différemment suivant que c'est Unicode(2 octets), UTF-8(multi-octet), etc.
 
Si l'algo traite la chaîne en flux d'octet, et pas en flux de caractère, c'est foutu

mais met un titre décent bon sang

c'est surement une connerie, mais il ne peut pas y avoir de problème d'endianess ?

J'ai changé le titre.  
 
Quant à l'encodage endian (High Endian / Low Endian), j'y avais pensé mais ça devrait me donner des String chiffrées complètement différentes alors que là, certaines portions correspondent. Ce sont certaines lettres qui sont "substituées" mais pas toutes...
 
Il doit y avoir un bug dans l'une des "fonctions" que j'utilise (procédure stockée, driver Oracle thin...). Ou alors une sorte de paramètre caché qu'on positionne de manière non intuitive...
 
Tiens, ça me fait aussi penser que ce problème de chiffrage se manifeste sur la même machine selon le mode de lancement de WebSphere. Lancée en ligne de commande, le serveur et l'appli démarrent normalement et tout marche. Mais lancé via le crontab, le serveur et l'appli démarrent mais le chiffrage déconne.
 

 
En recherchant sur le net, j'ai lu que toute String littérale (comme "toto" ) est stockée dans la JVM en Unicode. Le programmeur n'a pas à s'occuper de l'encodage sauf s'il fait des interfaces vers un système gérant un autre jeu de chars

 
Commme par exemple les bases de données qu'on peut créer chacune avec un encoding spécifique.

Le driver thin d'Oracle gère l'encodage vers la DB de manière transparente (lu sur le net pendant mes recherches)