Une question simple et bête pour changer un peut de la taille des void*:
J'ai un programme qui parse des entêtes de mails, donc, de l'ASCII.
Par exemple, je cherche le caractère ascii du signe égual dans un
buffer. Or, rien ne me dit que je peu chercher le caractère C '=' car a
priori l'encodage local n'est pas nécessairement de l'ASCII. Le
programme cherche donc la valeur numérique de ce caractère (61).
Je me demande si toutes ces précautions ne sont pas exagérées, d'autant
qu'elles alourdissent le programme (surtout lorsqu'il faut chercher des
chaînes de caractères, case insensitive, l'horreur!).
Bref, connaissez vous beaucoup d'architectures encore vivantes qui
utilisent un autre encodage que l'ASCII et sur lesquelles tournent des
serveurs de mails ? Sinon, je remplace tout ça par des belles strings C
et je pourrai utiliser strcmp et consorts...
Bref, connaissez vous beaucoup d'architectures encore vivantes qui utilisent un autre encodage que l'ASCII et sur lesquelles tournent des serveurs de mails ?
IBM continue à utiliser de l'EBCDIC sur les mainframes.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
cedric <rixed@happyleptic.NOSPAM.org> writes:
Bref, connaissez vous beaucoup d'architectures encore
vivantes qui utilisent un autre encodage que l'ASCII et
sur lesquelles tournent des serveurs de mails ?
IBM continue à utiliser de l'EBCDIC sur les mainframes.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Bref, connaissez vous beaucoup d'architectures encore vivantes qui utilisent un autre encodage que l'ASCII et sur lesquelles tournent des serveurs de mails ?
IBM continue à utiliser de l'EBCDIC sur les mainframes.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc
"Jean-Marc Bourguet" a écrit dans le message de news:
cedric writes:
Bref, connaissez vous beaucoup d'architectures encore vivantes qui utilisent un autre encodage que l'ASCII et sur lesquelles tournent des serveurs de mails ?
IBM continue à utiliser de l'EBCDIC sur les mainframes.
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme. La seule chose, c'est précisément qu'il faut éviter à tout prix les tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement if(car == '=') /* cherche '=' */
Le fait que le mainframe représente en interne les choses en EBCDIC ne change strictment rien, pour autant qu'on code en respectant la norme, par exemple en ne supposant pas que les caractères 'A'-'Z' et 'a'-'z' ont des valeurs contigues (c'est vrai en ASCII, faux en EBCDIC). De meme, on ne cherche pas les 'CR' et les 'LF' à coup de 13 et 10, comme on voit trop souvent mais avec les représentations C correctes 'n', 'r', etc.
Un de nos programmes (+/- 150.000 lignes de C) compile et tourne sans modifications sur plein de plateformes (Win32, tous les Unix, VMS(Vax) et aussi sur mainframe IBM (OS/390 et z/OS), Tandem, etc).
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
news:87oei6ahdz.fsf@news.bourguet.org...
cedric <rixed@happyleptic.NOSPAM.org> writes:
Bref, connaissez vous beaucoup d'architectures encore
vivantes qui utilisent un autre encodage que l'ASCII et
sur lesquelles tournent des serveurs de mails ?
IBM continue à utiliser de l'EBCDIC sur les mainframes.
Oui tout à fait. Et contrairement aux idées reçues, un programme C
bien écrit tourne sur un mainframe comme sur une autre plateforme. La
seule chose, c'est précisément qu'il faut éviter à tout prix les
tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement
if(car == '=') /* cherche '=' */
Le fait que le mainframe représente en interne les choses en EBCDIC
ne change strictment rien, pour autant qu'on code en respectant la
norme, par exemple en ne supposant pas que les caractères 'A'-'Z' et
'a'-'z' ont des valeurs contigues (c'est vrai en ASCII, faux en
EBCDIC). De meme, on ne cherche pas les 'CR' et les 'LF' à coup de 13
et 10, comme on voit trop souvent mais avec les représentations C
correctes 'n', 'r', etc.
Un de nos programmes (+/- 150.000 lignes de C) compile et tourne sans
modifications sur plein de plateformes (Win32, tous les Unix,
VMS(Vax) et aussi sur mainframe IBM (OS/390 et z/OS), Tandem, etc).
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Jean-Marc Bourguet" a écrit dans le message de news:
cedric writes:
Bref, connaissez vous beaucoup d'architectures encore vivantes qui utilisent un autre encodage que l'ASCII et sur lesquelles tournent des serveurs de mails ?
IBM continue à utiliser de l'EBCDIC sur les mainframes.
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme. La seule chose, c'est précisément qu'il faut éviter à tout prix les tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement if(car == '=') /* cherche '=' */
Le fait que le mainframe représente en interne les choses en EBCDIC ne change strictment rien, pour autant qu'on code en respectant la norme, par exemple en ne supposant pas que les caractères 'A'-'Z' et 'a'-'z' ont des valeurs contigues (c'est vrai en ASCII, faux en EBCDIC). De meme, on ne cherche pas les 'CR' et les 'LF' à coup de 13 et 10, comme on voit trop souvent mais avec les représentations C correctes 'n', 'r', etc.
Un de nos programmes (+/- 150.000 lignes de C) compile et tourne sans modifications sur plein de plateformes (Win32, tous les Unix, VMS(Vax) et aussi sur mainframe IBM (OS/390 et z/OS), Tandem, etc).
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Emmanuel Delahaye
Jean-Marc wrote on 09/11/04 :
Un de nos programmes (+/- 150.000 lignes de C) compile et tourne sans modifications sur plein de plateformes (Win32, tous les Unix, VMS(Vax) et aussi sur mainframe IBM (OS/390 et z/OS), Tandem, etc).
Merci de ce témoignage. Certains lecteurs s'imaginent toujours que le C portable est une utopie ou un mythe et ne comprennent pas notre insistance à bien différencier ce qui est portable de ce qui ne l'est pas...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Jean-Marc wrote on 09/11/04 :
Un de nos programmes (+/- 150.000 lignes de C) compile et tourne sans
modifications sur plein de plateformes (Win32, tous les Unix,
VMS(Vax) et aussi sur mainframe IBM (OS/390 et z/OS), Tandem, etc).
Merci de ce témoignage. Certains lecteurs s'imaginent toujours que le C
portable est une utopie ou un mythe et ne comprennent pas notre
insistance à bien différencier ce qui est portable de ce qui ne l'est
pas...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Un de nos programmes (+/- 150.000 lignes de C) compile et tourne sans modifications sur plein de plateformes (Win32, tous les Unix, VMS(Vax) et aussi sur mainframe IBM (OS/390 et z/OS), Tandem, etc).
Merci de ce témoignage. Certains lecteurs s'imaginent toujours que le C portable est une utopie ou un mythe et ne comprennent pas notre insistance à bien différencier ce qui est portable de ce qui ne l'est pas...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
cedric
Jean-Marc wrote:
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme. La seule chose, c'est précisément qu'il faut éviter à tout prix les tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails. Or, les RFC sont précis : le contenu des headers des mails est encodé en ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien 61... D'où mes soucis...
Il y a des serveurs smtp sur mainframes ? :-) Ils doivent alors utiliser un fonction de conversion de string du genre to_ascii(char *) ??
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle : int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une conversion ascii...
Jean-Marc wrote:
Oui tout à fait. Et contrairement aux idées reçues, un programme C
bien écrit tourne sur un mainframe comme sur une autre plateforme. La
seule chose, c'est précisément qu'il faut éviter à tout prix les
tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement
if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails.
Or, les RFC sont précis : le contenu des headers des mails est encodé en
ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais
bien 61... D'où mes soucis...
Il y a des serveurs smtp sur mainframes ? :-)
Ils doivent alors utiliser un fonction de conversion de string du
genre to_ascii(char *) ??
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle :
int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une
conversion ascii...
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme. La seule chose, c'est précisément qu'il faut éviter à tout prix les tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails. Or, les RFC sont précis : le contenu des headers des mails est encodé en ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien 61... D'où mes soucis...
Il y a des serveurs smtp sur mainframes ? :-) Ils doivent alors utiliser un fonction de conversion de string du genre to_ascii(char *) ??
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle : int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une conversion ascii...
Thomas Labourdette
cedric a écrit le mercredi 10 Novembre 2004 00:19 :
Jean-Marc wrote:
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme. La seule chose, c'est précisément qu'il faut éviter à tout prix les tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails. Or, les RFC sont précis : le contenu des headers des mails est encodé en ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien 61... D'où mes soucis...
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je cherche "From:"
@+ -- Yvan TILELAPIECE (signature aléatoire) PHYSIQUE QUANTIQUE C'est un homme aveugle, dans une pièce sombre, qui cherche un chat noir qui n'existe pas.
cedric a écrit le mercredi 10 Novembre 2004 00:19 :
Jean-Marc wrote:
Oui tout à fait. Et contrairement aux idées reçues, un programme C
bien écrit tourne sur un mainframe comme sur une autre plateforme. La
seule chose, c'est précisément qu'il faut éviter à tout prix les
tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement
if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails.
Or, les RFC sont précis : le contenu des headers des mails est encodé en
ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais
bien 61... D'où mes soucis...
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des
mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je
cherche "From:"
@+
--
Yvan TILELAPIECE (signature aléatoire)
PHYSIQUE QUANTIQUE
C'est un homme aveugle, dans une pièce sombre, qui cherche un chat noir
qui n'existe pas.
cedric a écrit le mercredi 10 Novembre 2004 00:19 :
Jean-Marc wrote:
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme. La seule chose, c'est précisément qu'il faut éviter à tout prix les tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails. Or, les RFC sont précis : le contenu des headers des mails est encodé en ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien 61... D'où mes soucis...
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je cherche "From:"
@+ -- Yvan TILELAPIECE (signature aléatoire) PHYSIQUE QUANTIQUE C'est un homme aveugle, dans une pièce sombre, qui cherche un chat noir qui n'existe pas.
Pierre Maurette
cedric a écrit:
Jean-Marc wrote:
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme. La seule chose, c'est précisément qu'il faut éviter à tout prix les tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails. Or, les RFC sont précis : le contenu des headers des mails est encodé en ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien 61... D'où mes soucis...
Il y a des serveurs smtp sur mainframes ? :-) Ils doivent alors utiliser un fonction de conversion de string du genre to_ascii(char *) ?? Ça dépend de la cible, donc du compilateur et de son paramètrage. Vous
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle : int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une conversion ascii... Un petit peu quand même. le "and binaire avec 127" garde les bits 0 à
6 et force le reste à "que des 0". Hors, l'ASCII de base est défini sur 7 bits. -- Pierre
cedric <rixed@happyleptic.NOSPAM.org> a écrit:
Jean-Marc wrote:
Oui tout à fait. Et contrairement aux idées reçues, un programme C
bien écrit tourne sur un mainframe comme sur une autre plateforme. La
seule chose, c'est précisément qu'il faut éviter à tout prix les
tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement
if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails.
Or, les RFC sont précis : le contenu des headers des mails est encodé en
ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais
bien 61... D'où mes soucis...
Il y a des serveurs smtp sur mainframes ? :-)
Ils doivent alors utiliser un fonction de conversion de string du
genre to_ascii(char *) ??
Ça dépend de la cible, donc du compilateur et de son paramètrage. Vous
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle :
int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une
conversion ascii...
Un petit peu quand même. le "and binaire avec 127" garde les bits 0 à
6 et force le reste à "que des 0". Hors, l'ASCII de base est défini
sur 7 bits.
--
Pierre
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme. La seule chose, c'est précisément qu'il faut éviter à tout prix les tests du genre:
if(car == 61) /* cherche '=' */
il suffit d'écrire tout à fait normalement if(car == '=') /* cherche '=' */
Heu... Oui sauf que là je parlais de parser des mails. Or, les RFC sont précis : le contenu des headers des mails est encodé en ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien 61... D'où mes soucis...
Il y a des serveurs smtp sur mainframes ? :-) Ils doivent alors utiliser un fonction de conversion de string du genre to_ascii(char *) ?? Ça dépend de la cible, donc du compilateur et de son paramètrage. Vous
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle : int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une conversion ascii... Un petit peu quand même. le "and binaire avec 127" garde les bits 0 à
6 et force le reste à "que des 0". Hors, l'ASCII de base est défini sur 7 bits. -- Pierre
Hamiral
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais que son programme doit pouvoir tourner sur des machines qui ne fonctionnent pas nativement en ASCII.
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des
mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je
cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais
que son programme doit pouvoir tourner sur des machines qui ne
fonctionnent pas nativement en ASCII.
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais que son programme doit pouvoir tourner sur des machines qui ne fonctionnent pas nativement en ASCII.
"Hamiral" a écrit dans le message de news:4191c6fd$0$15750$
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des
mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais que son programme doit pouvoir tourner sur des machines qui ne fonctionnent pas nativement en ASCII.
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés en ASCII et la représentation des caractères est trés codifiée. Par exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX ....}
Et bien ma fonction qui détecte le début du bloc 2 cherche: "{2:O" et pas autre chose!
Je répète: Mon programme est le **même** sur toutes les plateformes. ET il n'y a même pas de #define particuliers pour teser l'EBCDIC. On recompile, et c'est tout. Les seules adaptations à faire sont dues au fait que le système de fichier est totalement différent, et on place dans le JCL d'appel les références aux fichiers (datasets sur un mainframe) que le programme utilise, et point.
Vous devez comprendre ceci:
printf("Hello worldn"); /* OK toutes plateformes, EBCDIC aussi */ printf("%cello worldn", 73); /* NOT OK ! ASCII DEPENDANT */
Le fait que ça tourne sur un mainframe ou pas n'a aucune importance. Pour SMTP, c'est exactement pareil. si conversion il doit faire, pour affichage par exemple, il fera, point final. Et accessoirement, oui, il y a des serveurs SMTP sur les mainframes.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Hamiral" <hamiral@hamham.fr> a écrit dans le message de
news:4191c6fd$0$15750$7a628cd7@news.club-internet.fr...
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse
des
mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je
cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais
que son programme doit pouvoir tourner sur des machines qui ne
fonctionnent pas nativement en ASCII.
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés
en ASCII et la représentation des caractères est trés codifiée. Par
exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX
....}
Et bien ma fonction qui détecte le début du bloc 2 cherche: "{2:O" et
pas autre chose!
Je répète: Mon programme est le **même** sur toutes les plateformes.
ET il n'y a même pas de #define particuliers pour teser l'EBCDIC. On
recompile, et c'est tout. Les seules adaptations à faire sont dues au
fait que le système de fichier est totalement différent, et on place
dans le JCL d'appel les références aux fichiers (datasets sur un
mainframe) que le programme utilise, et point.
Vous devez comprendre ceci:
printf("Hello worldn"); /* OK toutes plateformes, EBCDIC aussi */
printf("%cello worldn", 73); /* NOT OK ! ASCII DEPENDANT */
Le fait que ça tourne sur un mainframe ou pas n'a aucune importance.
Pour SMTP, c'est exactement pareil. si conversion il doit faire, pour
affichage par exemple, il fera, point final. Et accessoirement, oui,
il y a des serveurs SMTP sur les mainframes.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Hamiral" a écrit dans le message de news:4191c6fd$0$15750$
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des
mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais que son programme doit pouvoir tourner sur des machines qui ne fonctionnent pas nativement en ASCII.
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés en ASCII et la représentation des caractères est trés codifiée. Par exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX ....}
Et bien ma fonction qui détecte le début du bloc 2 cherche: "{2:O" et pas autre chose!
Je répète: Mon programme est le **même** sur toutes les plateformes. ET il n'y a même pas de #define particuliers pour teser l'EBCDIC. On recompile, et c'est tout. Les seules adaptations à faire sont dues au fait que le système de fichier est totalement différent, et on place dans le JCL d'appel les références aux fichiers (datasets sur un mainframe) que le programme utilise, et point.
Vous devez comprendre ceci:
printf("Hello worldn"); /* OK toutes plateformes, EBCDIC aussi */ printf("%cello worldn", 73); /* NOT OK ! ASCII DEPENDANT */
Le fait que ça tourne sur un mainframe ou pas n'a aucune importance. Pour SMTP, c'est exactement pareil. si conversion il doit faire, pour affichage par exemple, il fera, point final. Et accessoirement, oui, il y a des serveurs SMTP sur les mainframes.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
cedric
Jean-Marc wrote:
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés en ASCII et la représentation des caractères est trés codifiée. Par exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX ....}
Et bien ma fonction qui détecte le début du bloc 2 cherche: "{2:O" et pas autre chose!
Je répète: Mon programme est le **même** sur toutes les plateformes.
Alors c'est que les fichiers Swift, eux ne sont pas les mêmes et ont étés recodés en ascii...
Sinon, si un serveur smtp codé en C et compilé avec un compilateur pour qui l'encodage local est l'ebcdic, recoit un 61 sur un socket (= en ascii), je ne voit pas trop comment il va deviner que ca correspond au '=' du compilateur...
Je répète moi aussi : il ne s'agit pas d'écrire (printf) mais de lire un flux codé sur une machine dont l'encodage est différent.
Jean-Marc wrote:
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés
en ASCII et la représentation des caractères est trés codifiée. Par
exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX
....}
Et bien ma fonction qui détecte le début du bloc 2 cherche: "{2:O" et
pas autre chose!
Je répète: Mon programme est le **même** sur toutes les plateformes.
Alors c'est que les fichiers Swift, eux ne sont pas les mêmes et ont
étés recodés en ascii...
Sinon, si un serveur smtp codé en C et compilé avec un compilateur pour
qui l'encodage local est l'ebcdic, recoit un 61 sur un socket (= en
ascii), je ne voit pas trop comment il va deviner que ca correspond au
'=' du compilateur...
Je répète moi aussi : il ne s'agit pas d'écrire (printf) mais de lire un
flux codé sur une machine dont l'encodage est différent.
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés en ASCII et la représentation des caractères est trés codifiée. Par exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX ....}
Et bien ma fonction qui détecte le début du bloc 2 cherche: "{2:O" et pas autre chose!
Je répète: Mon programme est le **même** sur toutes les plateformes.
Alors c'est que les fichiers Swift, eux ne sont pas les mêmes et ont étés recodés en ascii...
Sinon, si un serveur smtp codé en C et compilé avec un compilateur pour qui l'encodage local est l'ebcdic, recoit un 61 sur un socket (= en ascii), je ne voit pas trop comment il va deviner que ca correspond au '=' du compilateur...
Je répète moi aussi : il ne s'agit pas d'écrire (printf) mais de lire un flux codé sur une machine dont l'encodage est différent.
Marc Boyer
In article <4191d7c7$0$19317$, Jean-Marc wrote:
"Hamiral" a écrit dans le message de news:4191c6fd$0$15750$
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des
mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais que son programme doit pouvoir tourner sur des machines qui ne fonctionnent pas nativement en ASCII.
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés en ASCII et la représentation des caractères est trés codifiée. Par exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX ....}
Mais tu lis des fichiers texte je suppose, non ? Je penserais que le problème vient quand tu lis un flux dans une socket (ou connexion binaire équivalente): tu recois du binaire qui encode de l'ASCII. A moins que sur ces plateformes, tu puisses ouvrir les connexions en mode texte et qu'il te fasse de manière transparente la conversion binaire ASCII -> texte EBCDIC.
Non ?
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <4191d7c7$0$19317$ba620e4c@news.skynet.be>, Jean-Marc wrote:
"Hamiral" <hamiral@hamham.fr> a écrit dans le message de
news:4191c6fd$0$15750$7a628cd7@news.club-internet.fr...
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse
des
mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je
cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais
que son programme doit pouvoir tourner sur des machines qui ne
fonctionnent pas nativement en ASCII.
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés
en ASCII et la représentation des caractères est trés codifiée. Par
exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX
....}
Mais tu lis des fichiers texte je suppose, non ?
Je penserais que le problème vient quand tu lis un flux dans une
socket (ou connexion binaire équivalente): tu recois du binaire
qui encode de l'ASCII.
A moins que sur ces plateformes, tu puisses ouvrir les
connexions en mode texte et qu'il te fasse de manière transparente
la conversion binaire ASCII -> texte EBCDIC.
Non ?
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
"Hamiral" a écrit dans le message de news:4191c6fd$0$15750$
Je ne vois pas où est le souci. Tu cherches '=' point. Quand je parse des
mails et que je cherche From:, je ne cherche pas 70 114 111 109 58, je cherche "From:"
Le souci est que l'OP nous dit que les mails sont encodés en ASCII, mais que son programme doit pouvoir tourner sur des machines qui ne fonctionnent pas nativement en ASCII.
Ca n'a rien à voir! Moi je parse des messages Swift, ils sont codés en ASCII et la représentation des caractères est trés codifiée. Par exemple, l'entete d'un Swift commence par: "{1:XXXX ....}{2:O103XXXX ....}
Mais tu lis des fichiers texte je suppose, non ? Je penserais que le problème vient quand tu lis un flux dans une socket (ou connexion binaire équivalente): tu recois du binaire qui encode de l'ASCII. A moins que sur ces plateformes, tu puisses ouvrir les connexions en mode texte et qu'il te fasse de manière transparente la conversion binaire ASCII -> texte EBCDIC.
Non ?
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
