Fonction Chr() donne un résultat différents sur un windows européen ou japonais
4 réponses
schaperot
Bonjour à toutes et à tous,
L'application dont j'ai la charge fonctionne sans problème sur
des PC exécutant des windows occidentaux (français, allemand,
anglais... américain).
Cette même application présente des dysfonctionnement sur un
PC exécutant un windows japonais.
Après analyse, il s'agit de la fonction chr qui selon le système
d'exploitation ne renvoie pas le même caractère pour des codes
ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
Le but est de construire une chaine (string) par concaténation de caractères
obtenus via la fonction chr(). Les codes ascii varient de &h00 à &hFF.
Par la suite, l'application manipule cette chaine avec les fonctions
habituelles
(mid(), left(), right...).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jean-marc
"schaperot" wrote in message news:412308c1$0$13683$
Bonjour à toutes et à tous,
L'application dont j'ai la charge fonctionne sans problème sur des PC exécutant des windows occidentaux (français, allemand, anglais... américain).
Cette même application présente des dysfonctionnement sur un PC exécutant un windows japonais.
Après analyse, il s'agit de la fonction chr qui selon le système d'exploitation ne renvoie pas le même caractère pour des codes ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
Le but est de construire une chaine (string) par concaténation de
caractères
obtenus via la fonction chr(). Les codes ascii varient de &h00 à &hFF. Par la suite, l'application manipule cette chaine avec les fonctions habituelles (mid(), left(), right...).
Hello, c'est tout à fait normal: le jeu de caractères ASCII comporte les caractères de 0 à 128, parfaitement définis par la norme ANSI X3.4-1968 (voir aussi la ANSI X3.110-1983) Voici les table: ftp://dkuug.dk/i18n/WG15-collection/charmaps/ANSI_X3.4-1968 ftp://dkuug.dk/i18n/WG15-collection/charmaps/ANSI_X3.110-1983
Les caractères suivants, de 128 à 255 ne font PAS partie du jeu de caractères ASCII, mais ASCII étendu.
Les caractères de l'ASCII étendu dépendent d'autres normes, par exmeple l'ISO Latin1 http://www.indwes.edu/Faculty/bcupp/things/latin1.htm
Donc, quand tu dis:
Après analyse, il s'agit de la fonction chr qui selon le système d'exploitation ne renvoie pas le même caractère pour des codes ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes dont la représentation peut varier librement en fonction de la machine, du pays, de la page de code utilisée, etc.
Dans ton cas, une solution est de définir une table de correspondance pour les codes étendus, de 128 à 255. Tu devras construitre cette table en fonction de tes besoins.
Jean-marc
"schaperot" <NoSpamSchaperot@free.fr> wrote in message
news:412308c1$0$13683$636a15ce@news.free.fr...
Bonjour à toutes et à tous,
L'application dont j'ai la charge fonctionne sans problème sur
des PC exécutant des windows occidentaux (français, allemand,
anglais... américain).
Cette même application présente des dysfonctionnement sur un
PC exécutant un windows japonais.
Après analyse, il s'agit de la fonction chr qui selon le système
d'exploitation ne renvoie pas le même caractère pour des codes
ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
Le but est de construire une chaine (string) par concaténation de
caractères
obtenus via la fonction chr(). Les codes ascii varient de &h00 à &hFF.
Par la suite, l'application manipule cette chaine avec les fonctions
habituelles
(mid(), left(), right...).
Hello,
c'est tout à fait normal:
le jeu de caractères ASCII comporte les caractères de 0 à 128, parfaitement
définis par la norme ANSI X3.4-1968 (voir aussi la ANSI X3.110-1983)
Voici les table:
ftp://dkuug.dk/i18n/WG15-collection/charmaps/ANSI_X3.4-1968
ftp://dkuug.dk/i18n/WG15-collection/charmaps/ANSI_X3.110-1983
Les caractères suivants, de 128 à 255 ne font PAS partie du jeu de
caractères ASCII, mais ASCII étendu.
Les caractères de l'ASCII étendu dépendent d'autres normes, par exmeple
l'ISO Latin1
http://www.indwes.edu/Faculty/bcupp/things/latin1.htm
Donc, quand tu dis:
Après analyse, il s'agit de la fonction chr qui selon le système
d'exploitation ne renvoie pas le même caractère pour des codes
ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes dont
la représentation peut varier librement en fonction de la machine, du pays,
de la page de code utilisée, etc.
Dans ton cas, une solution est de définir une table de correspondance pour
les codes étendus, de 128 à 255. Tu devras construitre cette table en
fonction de tes besoins.
"schaperot" wrote in message news:412308c1$0$13683$
Bonjour à toutes et à tous,
L'application dont j'ai la charge fonctionne sans problème sur des PC exécutant des windows occidentaux (français, allemand, anglais... américain).
Cette même application présente des dysfonctionnement sur un PC exécutant un windows japonais.
Après analyse, il s'agit de la fonction chr qui selon le système d'exploitation ne renvoie pas le même caractère pour des codes ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
Le but est de construire une chaine (string) par concaténation de
caractères
obtenus via la fonction chr(). Les codes ascii varient de &h00 à &hFF. Par la suite, l'application manipule cette chaine avec les fonctions habituelles (mid(), left(), right...).
Hello, c'est tout à fait normal: le jeu de caractères ASCII comporte les caractères de 0 à 128, parfaitement définis par la norme ANSI X3.4-1968 (voir aussi la ANSI X3.110-1983) Voici les table: ftp://dkuug.dk/i18n/WG15-collection/charmaps/ANSI_X3.4-1968 ftp://dkuug.dk/i18n/WG15-collection/charmaps/ANSI_X3.110-1983
Les caractères suivants, de 128 à 255 ne font PAS partie du jeu de caractères ASCII, mais ASCII étendu.
Les caractères de l'ASCII étendu dépendent d'autres normes, par exmeple l'ISO Latin1 http://www.indwes.edu/Faculty/bcupp/things/latin1.htm
Donc, quand tu dis:
Après analyse, il s'agit de la fonction chr qui selon le système d'exploitation ne renvoie pas le même caractère pour des codes ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes dont la représentation peut varier librement en fonction de la machine, du pays, de la page de code utilisée, etc.
Dans ton cas, une solution est de définir une table de correspondance pour les codes étendus, de 128 à 255. Tu devras construitre cette table en fonction de tes besoins.
Jean-marc
schaperot
> tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes
dont
la représentation peut varier librement en fonction de la machine, du
pays,
de la page de code utilisée, etc.
Dans ton cas, une solution est de définir une table de correspondance pour les codes étendus, de 128 à 255. Tu devras construitre cette table en fonction de tes besoins.
Merci de ta réponse, je vais cependant apporter une information supplmentaires.
Les caractères ne sont pas destinés à être affichés, mais à être stockés. Après manipulation des chaines, j'utilise la fonction Asc() pour retrouver le code ascii du caractère stocké à la Nième position. C'est durant la récupération que je rencontre le pb. En fait, le problème vient peut-être de la fonction Asc... Je ne sais pas ce qui est stocké réellement dans la string.
Pour résumer : Windows occidental Asc(Chr(244))$4 Asc(Chr(245))$5
Windows japonais Asc(Chr(244))=0 Asc(Chr(245))=0
> tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes
dont
la représentation peut varier librement en fonction de la machine, du
pays,
de la page de code utilisée, etc.
Dans ton cas, une solution est de définir une table de correspondance pour
les codes étendus, de 128 à 255. Tu devras construitre cette table en
fonction de tes besoins.
Merci de ta réponse, je vais cependant apporter une information
supplmentaires.
Les caractères ne sont pas destinés à être affichés, mais à être stockés.
Après
manipulation des chaines, j'utilise la fonction Asc() pour retrouver le code
ascii
du caractère stocké à la Nième position. C'est durant la récupération que je
rencontre
le pb. En fait, le problème vient peut-être de la fonction Asc... Je ne sais
pas ce qui
est stocké réellement dans la string.
Pour résumer :
Windows occidental
Asc(Chr(244))$4
Asc(Chr(245))$5
> tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes
dont
la représentation peut varier librement en fonction de la machine, du
pays,
de la page de code utilisée, etc.
Dans ton cas, une solution est de définir une table de correspondance pour les codes étendus, de 128 à 255. Tu devras construitre cette table en fonction de tes besoins.
Merci de ta réponse, je vais cependant apporter une information supplmentaires.
Les caractères ne sont pas destinés à être affichés, mais à être stockés. Après manipulation des chaines, j'utilise la fonction Asc() pour retrouver le code ascii du caractère stocké à la Nième position. C'est durant la récupération que je rencontre le pb. En fait, le problème vient peut-être de la fonction Asc... Je ne sais pas ce qui est stocké réellement dans la string.
Pour résumer : Windows occidental Asc(Chr(244))$4 Asc(Chr(245))$5
Windows japonais Asc(Chr(244))=0 Asc(Chr(245))=0
Jean-Marc
"schaperot" a écrit dans le message de news:41237800$0$27153$
> tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes dont > la représentation peut varier librement en fonction de la machine, du pays, > de la page de code utilisée, etc. > > Dans ton cas, une solution est de définir une table de correspondance
pour
> les codes étendus, de 128 à 255. Tu devras construitre cette table en > fonction de tes besoins.
Merci de ta réponse, je vais cependant apporter une information supplmentaires.
Les caractères ne sont pas destinés à être affichés, mais à être stockés. Après manipulation des chaines, j'utilise la fonction Asc() pour retrouver le
code
ascii du caractère stocké à la Nième position. C'est durant la récupération que
je
rencontre le pb. En fait, le problème vient peut-être de la fonction Asc... Je ne
sais
pas ce qui est stocké réellement dans la string.
Pour résumer : Windows occidental Asc(Chr(244))$4 Asc(Chr(245))$5
Windows japonais Asc(Chr(244))=0 Asc(Chr(245))=0
Il faut aborder le problème sous un autre angle alors. Comment se fait l'acquisition de la string que tu dois traîter? entrée au clavier ? lecture depuis un fichier ? car ce 244 et 245 que tu décris, il viennent bien de qq part. Si il viennent d'un fichier, alors une lecture en mode binaire sera la solution.
Jean-marc
"schaperot" <NoSpamSchaperot@free.fr> a écrit dans le message de
news:41237800$0$27153$636a15ce@news.free.fr...
> tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes
dont
> la représentation peut varier librement en fonction de la machine, du
pays,
> de la page de code utilisée, etc.
>
> Dans ton cas, une solution est de définir une table de correspondance
pour
> les codes étendus, de 128 à 255. Tu devras construitre cette table en
> fonction de tes besoins.
Merci de ta réponse, je vais cependant apporter une information
supplmentaires.
Les caractères ne sont pas destinés à être affichés, mais à être stockés.
Après
manipulation des chaines, j'utilise la fonction Asc() pour retrouver le
code
ascii
du caractère stocké à la Nième position. C'est durant la récupération que
je
rencontre
le pb. En fait, le problème vient peut-être de la fonction Asc... Je ne
sais
pas ce qui
est stocké réellement dans la string.
Pour résumer :
Windows occidental
Asc(Chr(244))$4
Asc(Chr(245))$5
Windows japonais
Asc(Chr(244))=0
Asc(Chr(245))=0
Il faut aborder le problème sous un autre angle alors.
Comment se fait l'acquisition de la string que tu dois traîter? entrée au
clavier ? lecture depuis un fichier ? car ce 244 et 245 que tu décris, il
viennent bien de qq part. Si il viennent d'un fichier, alors une lecture en
mode binaire sera la solution.
"schaperot" a écrit dans le message de news:41237800$0$27153$
> tout est clair: 244 et 245 ne sont PAS des codes ASCII, mais des codes dont > la représentation peut varier librement en fonction de la machine, du pays, > de la page de code utilisée, etc. > > Dans ton cas, une solution est de définir une table de correspondance
pour
> les codes étendus, de 128 à 255. Tu devras construitre cette table en > fonction de tes besoins.
Merci de ta réponse, je vais cependant apporter une information supplmentaires.
Les caractères ne sont pas destinés à être affichés, mais à être stockés. Après manipulation des chaines, j'utilise la fonction Asc() pour retrouver le
code
ascii du caractère stocké à la Nième position. C'est durant la récupération que
je
rencontre le pb. En fait, le problème vient peut-être de la fonction Asc... Je ne
sais
pas ce qui est stocké réellement dans la string.
Pour résumer : Windows occidental Asc(Chr(244))$4 Asc(Chr(245))$5
Windows japonais Asc(Chr(244))=0 Asc(Chr(245))=0
Il faut aborder le problème sous un autre angle alors. Comment se fait l'acquisition de la string que tu dois traîter? entrée au clavier ? lecture depuis un fichier ? car ce 244 et 245 que tu décris, il viennent bien de qq part. Si il viennent d'un fichier, alors une lecture en mode binaire sera la solution.
Jean-marc
ng
Salut,
Petite note au passage qui n'a rien à voir avec le problème, utilise plutot Chr$() que Chr(), idem pour Left$(), Mid$(), Right$(), Trim$()...
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
schaperot a écrit :
Bonjour à toutes et à tous,
L'application dont j'ai la charge fonctionne sans problème sur des PC exécutant des windows occidentaux (français, allemand, anglais... américain).
Cette même application présente des dysfonctionnement sur un PC exécutant un windows japonais.
Après analyse, il s'agit de la fonction chr qui selon le système d'exploitation ne renvoie pas le même caractère pour des codes ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
Le but est de construire une chaine (string) par concaténation de caractères obtenus via la fonction chr(). Les codes ascii varient de &h00 à &hFF. Par la suite, l'application manipule cette chaine avec les fonctions habituelles (mid(), left(), right...).
Merci de vos avis et idées.
Salut,
Petite note au passage qui n'a rien à voir avec le problème, utilise plutot
Chr$() que Chr(), idem pour Left$(), Mid$(), Right$(), Trim$()...
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
http://apisvb.europe.webmatrixhosting.net/
schaperot <NoSpamSchaperot@free.fr> a écrit :
Bonjour à toutes et à tous,
L'application dont j'ai la charge fonctionne sans problème sur
des PC exécutant des windows occidentaux (français, allemand,
anglais... américain).
Cette même application présente des dysfonctionnement sur un
PC exécutant un windows japonais.
Après analyse, il s'agit de la fonction chr qui selon le système
d'exploitation ne renvoie pas le même caractère pour des codes
ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
Le but est de construire une chaine (string) par concaténation de
caractères obtenus via la fonction chr(). Les codes ascii varient de
&h00 à &hFF.
Par la suite, l'application manipule cette chaine avec les fonctions
habituelles
(mid(), left(), right...).
Petite note au passage qui n'a rien à voir avec le problème, utilise plutot Chr$() que Chr(), idem pour Left$(), Mid$(), Right$(), Trim$()...
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
schaperot a écrit :
Bonjour à toutes et à tous,
L'application dont j'ai la charge fonctionne sans problème sur des PC exécutant des windows occidentaux (français, allemand, anglais... américain).
Cette même application présente des dysfonctionnement sur un PC exécutant un windows japonais.
Après analyse, il s'agit de la fonction chr qui selon le système d'exploitation ne renvoie pas le même caractère pour des codes ascii tels que 244, 245. Je n'ai pas pu tester tous les codes ascii.
Le but est de construire une chaine (string) par concaténation de caractères obtenus via la fonction chr(). Les codes ascii varient de &h00 à &hFF. Par la suite, l'application manipule cette chaine avec les fonctions habituelles (mid(), left(), right...).
