Discussion :

[bleuerouge]

Bonjour,
Lors du passage d'un paramètre dans ma DLL les caractères étendues (supérieur à 127) sont mal interprétés. Hors le problème survient de la conversion de mon char * en unsigned char *, qui s'effectue via un simple cast, les caractères sont érronés.

Existe t il une méthode de conversion clair pour prendre en compte ses dit caractères ?

Merci d'avance

[3DArchi]

J'ai l'impression qu'il manque quelques infos?
En brut: aurais-tu une appli en UNICODE et une DLL en non UNICODE?
Sinon, il faudrait un peu plus d'info?

[bleuerouge]

la DLL est en C++ (ecrit avec visual c++ 6) , l'application de test est en delphi 2006 (win32); l'application envoi un tableau de pchar qui est réceptionné en char *, hors tout les caractères du jeu étendu sont systématiquements erronés.

[3DArchi]

Je ne connais pas DELPHI. Quelques questions de bases : lorsque tu invoques la DLL depuis ton application, maîtrises-tu la façon dont sont passés les paramètres ? As-tu regardé en mémoire si tu recevais correctement ton tableau de char (dans un premier temps en non étendu).

[Laurent Gomila]

Les codes de caractères supérieurs à 127 ne sont pas standards et peuvent donc être interprétés différemment par ton programme et ta DLL. Commence donc par vérifier qu'ils utilisent tous deux le même jeu de caractères.

[bleuerouge]

Les codes de caractères supérieurs à 127 ne sont pas standards et peuvent donc être interprétés différemment par ton programme et ta DLL. Commence donc par vérifier qu'ils utilisent tous deux le même jeu de caractères.

Les 2 utilisent le même jeu de caractères , la seul chose qui change c'est qu'à un moment donné, la conversion change complètement le contenu de la chaine de caractère.

[Laurent Gomila]

C'est contradictoire, tu parles de contenu changé suite à une conversion, mais dans ton premier message tu parles de simple cast de char* en unsigned char*.

Si tu nous montrais plutôt du code ?

[bleuerouge]

Solution trouvé qui n'a rien à voir, les jeux de caractères étaient tout simplement différent (ansi et ASCII)

la solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
	if (!isascii(p)) {
			CharToOem((const char *) &p,&df);
			_message[i]= df;
	}

[nicroman]

Heu... j'y perds mon latin là....

En quoi le contenu peut-il être différent ?
Il peut être INTERPRETE différemment, mais c'est la même chose qui est passé que ce soit un char* ou un unsigned char*

Donc la question est plutôt... d'ou viennent les caractères ... et comment fais tu pour savoir qu'ils ne sont pas bons ?

Sous Windows...
Si c'est sous le débugeur.. celui-ci utilise (par défaut le systeme 'ANSI', c'est à dire le codepage par défaut du langage sélectionné par l'utilisateur courant).
Certains fonctions DOS (ou anciennes) utilisent le système OEM.
Mais dans tous les cas... depuis environ 10 ans (puisqu'il existe les librairies nécessaires pour Windows 95)... il est préférable d'utiliser UNICODE.

[Médinoc]

@nicroman : Le problème majeur, c'est que la console, à moins que tu la lises en Unicode, est en OEM.

Donc, un simple fgets() te donnera du texte en OEM, et si tu rediriges un fichier vers ton programme, il s'attendra également à ce que le fichier soit en OEM ! (genre, un fichier écrit avec EDIT).