Conversion d'un char en unsigned char (caractere étendu)

Version imprimable

15/07/2008, 09h33
bleuerouge

Conversion d'un char en unsigned char (caractere étendu)

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
15/07/2008, 09h59
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?
15/07/2008, 10h03
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.
15/07/2008, 10h08
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).
15/07/2008, 10h36
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.
15/07/2008, 11h01
bleuerouge

Citation:

Envoyé par 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.

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.
15/07/2008, 11h41
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 ?
15/07/2008, 14h30
bleuerouge
Solution trouvé qui n'a rien à voir, les jeux de caractères étaient tout simplement différent (ansi et ASCII)

la solution :
Code:

1 2 3 4 5 if (!isascii(p)) { CharToOem((const char *) &p,&df); _message[i]= df; }
16/07/2008, 01h47
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.
16/07/2008, 11h01
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).