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...
Ça dépend de la cible, donc du compilateur et de son paramètrage. Vous pouvez utiliser '=' et placer un: #if '=' == 61 ....... #else /* du #if '=' == 61 */ # error "Plateforme caca, j'arrête" #endif
Si un jour ça gueule, il sera temps de réagir.
Oui, ca va surement finir comme ca. Et ca ne geulera d'ailleurs probablement jamais. Merci de la suggestion.
(à 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.
Oui, mais je doute que sur un mainframe, par exemple, et ceci dit sans vouloir énerver personne, ladite fonction parvienne à convertir par ce moyen un caractère local en ascii ;) Disons que je trouve le nom de la fonction un peu trompeur.
Pierre Maurette wrote:
Ça dépend de la cible, donc du compilateur et de son paramètrage. Vous
pouvez utiliser '=' et placer un:
#if '=' == 61
.......
#else /* du #if '=' == 61 */
# error "Plateforme caca, j'arrête"
#endif
Si un jour ça gueule, il sera temps de réagir.
Oui, ca va surement finir comme ca. Et ca ne geulera d'ailleurs
probablement jamais.
Merci de la suggestion.
(à 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.
Oui, mais je doute que sur un mainframe, par exemple, et ceci dit sans
vouloir énerver personne, ladite fonction parvienne à convertir par ce
moyen un caractère local en ascii ;) Disons que je trouve le nom de la
fonction un peu trompeur.
Ça dépend de la cible, donc du compilateur et de son paramètrage. Vous pouvez utiliser '=' et placer un: #if '=' == 61 ....... #else /* du #if '=' == 61 */ # error "Plateforme caca, j'arrête" #endif
Si un jour ça gueule, il sera temps de réagir.
Oui, ca va surement finir comme ca. Et ca ne geulera d'ailleurs probablement jamais. Merci de la suggestion.
(à 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.
Oui, mais je doute que sur un mainframe, par exemple, et ceci dit sans vouloir énerver personne, ladite fonction parvienne à convertir par ce moyen un caractère local en ascii ;) Disons que je trouve le nom de la fonction un peu trompeur.
cedric
Marc Boyer wrote:
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.
Quand bien même, comment saurait-il que le flux entrant est encodé en ASCII ?
Marc Boyer wrote:
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.
Quand bien même, comment saurait-il que le flux entrant est encodé en
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.
Quand bien même, comment saurait-il que le flux entrant est encodé en ASCII ?
cedric
cedric wrote:
Alors c'est que les fichiers Swift, eux ne sont pas les mêmes et ont étés recodés en ascii...
Il faut lire bien sur : recodés en ebcdic.
cedric wrote:
Alors c'est que les fichiers Swift, eux ne sont pas les mêmes et ont
étés recodés en ascii...
Alors c'est que les fichiers Swift, eux ne sont pas les mêmes et ont étés recodés en ascii...
Il faut lire bien sur : recodés en ebcdic.
Jean-Marc Bourguet
"Jean-Marc" writes:
"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!
Si.
Ca depend ou il se trouve dans la chaine. Si c'est lui qui gere la reception directe, il doit traiter le fait que les en-tetes sont en ASCII pour les interpreter (un transcodage bourrin de tout le message pose probleme car le corps n'est pas necessairement en ASCII, voir les spam coreens pour ceux qui en doutent) et vraissemblablement les transcoder pour que la suite des traitements ne s'occupe pas de ce detail.
S'il recupere ses messages dans un fichier, la il doit savoir ce que fait le systeme. Il me semble raisonnable que la partie ayant assure la reception ait effectue le transcodage pour les entetes (et peut-etre meme pour le corps) auquel cas il faut utiliser des constantes litterales, nous sommes d'accord.
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!
Le transcodage a ete effectue quelque part. Et le programme qui l'a fait a du savoir que c'etait de l'ASCII.
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
"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!
Si.
Ca depend ou il se trouve dans la chaine. Si c'est lui qui gere la
reception directe, il doit traiter le fait que les en-tetes sont en
ASCII pour les interpreter (un transcodage bourrin de tout le message
pose probleme car le corps n'est pas necessairement en ASCII, voir les
spam coreens pour ceux qui en doutent) et vraissemblablement les
transcoder pour que la suite des traitements ne s'occupe pas de ce
detail.
S'il recupere ses messages dans un fichier, la il doit savoir ce que
fait le systeme. Il me semble raisonnable que la partie ayant assure
la reception ait effectue le transcodage pour les entetes (et
peut-etre meme pour le corps) auquel cas il faut utiliser des
constantes litterales, nous sommes d'accord.
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!
Le transcodage a ete effectue quelque part. Et le programme qui l'a
fait a du savoir que c'etait de l'ASCII.
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
"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!
Si.
Ca depend ou il se trouve dans la chaine. Si c'est lui qui gere la reception directe, il doit traiter le fait que les en-tetes sont en ASCII pour les interpreter (un transcodage bourrin de tout le message pose probleme car le corps n'est pas necessairement en ASCII, voir les spam coreens pour ceux qui en doutent) et vraissemblablement les transcoder pour que la suite des traitements ne s'occupe pas de ce detail.
S'il recupere ses messages dans un fichier, la il doit savoir ce que fait le systeme. Il me semble raisonnable que la partie ayant assure la reception ait effectue le transcodage pour les entetes (et peut-etre meme pour le corps) auquel cas il faut utiliser des constantes litterales, nous sommes d'accord.
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!
Le transcodage a ete effectue quelque part. Et le programme qui l'a fait a du savoir que c'etait de l'ASCII.
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 Bourguet
Marc Boyer writes:
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.
Meme si c'etait le cas, la transformation a faire depend du message: les entetes sont en ASCII (et encore...) mais le corps a un encodage quasiment libre.
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
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
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.
Meme si c'etait le cas, la transformation a faire depend du message:
les entetes sont en ASCII (et encore...) mais le corps a un encodage
quasiment libre.
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
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.
Meme si c'etait le cas, la transformation a faire depend du message: les entetes sont en ASCII (et encore...) mais le corps a un encodage quasiment libre.
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
Marc Boyer
Jean-Marc Bourguet wrote:
Marc Boyer writes:
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.
Meme si c'etait le cas, la transformation a faire depend du message: les entetes sont en ASCII (et encore...) mais le corps a un encodage quasiment libre.
Disons que, il me semble qu'il fut un temps ou les gens respectaient le fait que c'était de l'ASCII et où ils faisaient un encodage (les uuencode et base 64 si mes souvenirs sont bons). Non ?
Mais actuellement, oui, il semble qu'on y trouve de tout.
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.
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
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.
Meme si c'etait le cas, la transformation a faire depend du message:
les entetes sont en ASCII (et encore...) mais le corps a un encodage
quasiment libre.
Disons que, il me semble qu'il fut un temps ou les gens
respectaient le fait que c'était de l'ASCII et où ils
faisaient un encodage (les uuencode et base 64 si mes
souvenirs sont bons).
Non ?
Mais actuellement, oui, il semble qu'on y trouve de tout.
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.
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.
Meme si c'etait le cas, la transformation a faire depend du message: les entetes sont en ASCII (et encore...) mais le corps a un encodage quasiment libre.
Disons que, il me semble qu'il fut un temps ou les gens respectaient le fait que c'était de l'ASCII et où ils faisaient un encodage (les uuencode et base 64 si mes souvenirs sont bons). Non ?
Mais actuellement, oui, il semble qu'on y trouve de tout.
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.
Marc Boyer
cedric wrote:
Marc Boyer wrote:
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.
Quand bien même, comment saurait-il que le flux entrant est encodé en ASCII ?
Oui, bien sur, en le lui précisant à l'ouverture.
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.
cedric wrote:
Marc Boyer wrote:
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.
Quand bien même, comment saurait-il que le flux entrant est encodé en
ASCII ?
Oui, bien sur, en le lui précisant à l'ouverture.
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.
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.
Quand bien même, comment saurait-il que le flux entrant est encodé en ASCII ?
Oui, bien sur, en le lui précisant à l'ouverture.
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.
Jean-Marc Bourguet
Marc Boyer writes:
Jean-Marc Bourguet wrote:
Marc Boyer writes:
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.
Meme si c'etait le cas, la transformation a faire depend du message: les entetes sont en ASCII (et encore...) mais le corps a un encodage quasiment libre.
Disons que, il me semble qu'il fut un temps ou les gens respectaient le fait que c'était de l'ASCII et où ils faisaient un encodage (les uuencode et base 64 si mes souvenirs sont bons). Non?
Pour chaque partie du corps d'un message, il y a un codage de transfert qui indique comment il faut transformer ce qui est recu pour avoir le vrai contenu (le probleme a resoudre ici est que le systeme a ete concu pour transporter des infos sur 7 bits, le 8ieme pouvait etre perdu). Il y en a plusieurs possibles, certains plus adaptes que d'autres a certain contenu. Base64 est une solution adaptee a un vrai contenu binaire par exemple.
Et il y a une indication sur la maniere dont il faut interpreter le resultat (c'est le content-type). Ca peut etre un GIF, un PDF ou du texte. Dans ce dernier cas, il y a une indication du charset utilise pour le texte (ASCII, Latin-1,...)
Il fut un temps ou il n'y avait pas de moyens officiels pour donner ces informations. Les messages etaient alors en ASCII 7 bits et pour le reste on se debrouillait comme on pouvait, se mettre d'accord avec son correspondant pour que le message soit interprete comme du Latin-1 ou du Cyrillique ou du grec et esperer que rien ne viennent modifier le 8ieme bit (ce qui arrivait parfois avec des effets plus ou moins amusant). Mettre un fichier encode avec uuencode dans le corps etait la solution pour les binaires.
uuencode et base64 cherchent a resoudre le meme probleme: encoder du binaire dans un flux concu pour transporter des caracteres. Si j'ai bonne memoire base64 a deux avantages sur uuencode: il n'y a qu'une version (il y a au moins deux versions legerement differente d'uuencode) et il est plus robuste a des changements de charset.
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
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
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.
Meme si c'etait le cas, la transformation a faire depend du message:
les entetes sont en ASCII (et encore...) mais le corps a un encodage
quasiment libre.
Disons que, il me semble qu'il fut un temps ou les gens
respectaient le fait que c'était de l'ASCII et où ils faisaient un
encodage (les uuencode et base 64 si mes souvenirs sont bons). Non?
Pour chaque partie du corps d'un message, il y a un codage de
transfert qui indique comment il faut transformer ce qui est recu pour
avoir le vrai contenu (le probleme a resoudre ici est que le systeme a
ete concu pour transporter des infos sur 7 bits, le 8ieme pouvait etre
perdu). Il y en a plusieurs possibles, certains plus adaptes que
d'autres a certain contenu. Base64 est une solution adaptee a un vrai
contenu binaire par exemple.
Et il y a une indication sur la maniere dont il faut interpreter le
resultat (c'est le content-type). Ca peut etre un GIF, un PDF ou du
texte. Dans ce dernier cas, il y a une indication du charset utilise
pour le texte (ASCII, Latin-1,...)
Il fut un temps ou il n'y avait pas de moyens officiels pour donner
ces informations. Les messages etaient alors en ASCII 7 bits et pour
le reste on se debrouillait comme on pouvait, se mettre d'accord avec
son correspondant pour que le message soit interprete comme du Latin-1
ou du Cyrillique ou du grec et esperer que rien ne viennent modifier
le 8ieme bit (ce qui arrivait parfois avec des effets plus ou moins
amusant). Mettre un fichier encode avec uuencode dans le corps etait
la solution pour les binaires.
uuencode et base64 cherchent a resoudre le meme probleme: encoder du
binaire dans un flux concu pour transporter des caracteres. Si j'ai
bonne memoire base64 a deux avantages sur uuencode: il n'y a qu'une
version (il y a au moins deux versions legerement differente
d'uuencode) et il est plus robuste a des changements de charset.
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
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.
Meme si c'etait le cas, la transformation a faire depend du message: les entetes sont en ASCII (et encore...) mais le corps a un encodage quasiment libre.
Disons que, il me semble qu'il fut un temps ou les gens respectaient le fait que c'était de l'ASCII et où ils faisaient un encodage (les uuencode et base 64 si mes souvenirs sont bons). Non?
Pour chaque partie du corps d'un message, il y a un codage de transfert qui indique comment il faut transformer ce qui est recu pour avoir le vrai contenu (le probleme a resoudre ici est que le systeme a ete concu pour transporter des infos sur 7 bits, le 8ieme pouvait etre perdu). Il y en a plusieurs possibles, certains plus adaptes que d'autres a certain contenu. Base64 est une solution adaptee a un vrai contenu binaire par exemple.
Et il y a une indication sur la maniere dont il faut interpreter le resultat (c'est le content-type). Ca peut etre un GIF, un PDF ou du texte. Dans ce dernier cas, il y a une indication du charset utilise pour le texte (ASCII, Latin-1,...)
Il fut un temps ou il n'y avait pas de moyens officiels pour donner ces informations. Les messages etaient alors en ASCII 7 bits et pour le reste on se debrouillait comme on pouvait, se mettre d'accord avec son correspondant pour que le message soit interprete comme du Latin-1 ou du Cyrillique ou du grec et esperer que rien ne viennent modifier le 8ieme bit (ce qui arrivait parfois avec des effets plus ou moins amusant). Mettre un fichier encode avec uuencode dans le corps etait la solution pour les binaires.
uuencode et base64 cherchent a resoudre le meme probleme: encoder du binaire dans un flux concu pour transporter des caracteres. Si j'ai bonne memoire base64 a deux avantages sur uuencode: il n'y a qu'une version (il y a au moins deux versions legerement differente d'uuencode) et il est plus robuste a des changements de charset.
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
Antoine Leca
En 41912e85$0$16547$, Jean-Marc va escriure:
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.
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme.
Oui.
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 '=' */
SAUF dans le cas où tu traites un flux brut venant de l'Internet (ou d'un truc du même genre, par exemple un lien NetBIOS).
En gros, tu as deux solutions:
-- utiliser une option au niveau des sockets pour traduire entre l'ASCII (extérieur) et l'EBCDIC (interne au programme), et alors tu peux garder ta solution avec '=' mais tu ne traites plus un flux brut, ce qui peux être un problème (par exemple si tu dois décoder du UTF-8 non signalé par ailleurs)
-- ne pas utiliser cette option, mais alors tu dois faire toi-même le décodage ASCII-EBCDIC en entrée; et à ce moment-là, tu vas te retrouver avec le pépin ci-dessus pour traiter le QP.
Évidemment, aucun des deux cas n'est vraiment optimum, il faut chercher le moindre mal. Je suis comme toi, je préfère et de très loin la première solution, mais je comprends qu'il y ait des cas où le seconde sera meilleure.
http://httpd.apache.org/docs/ebcdic.html est intéressant.
Antoine
En 41912e85$0$16547$ba620e4c@news.skynet.be, Jean-Marc va escriure:
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.
Oui tout à fait. Et contrairement aux idées reçues, un programme C
bien écrit tourne sur un mainframe comme sur une autre plateforme.
Oui.
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 '=' */
SAUF dans le cas où tu traites un flux brut venant de l'Internet (ou d'un
truc du même genre, par exemple un lien NetBIOS).
En gros, tu as deux solutions:
-- utiliser une option au niveau des sockets pour traduire entre l'ASCII
(extérieur) et l'EBCDIC (interne au programme), et alors tu peux garder ta
solution avec '=' mais tu ne traites plus un flux brut, ce qui peux être un
problème (par exemple si tu dois décoder du UTF-8 non signalé par ailleurs)
-- ne pas utiliser cette option, mais alors tu dois faire toi-même le
décodage ASCII-EBCDIC en entrée; et à ce moment-là, tu vas te retrouver avec
le pépin ci-dessus pour traiter le QP.
Évidemment, aucun des deux cas n'est vraiment optimum, il faut chercher le
moindre mal. Je suis comme toi, je préfère et de très loin la première
solution, mais je comprends qu'il y ait des cas où le seconde sera
meilleure.
http://httpd.apache.org/docs/ebcdic.html est intéressant.
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.
Oui tout à fait. Et contrairement aux idées reçues, un programme C bien écrit tourne sur un mainframe comme sur une autre plateforme.
Oui.
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 '=' */
SAUF dans le cas où tu traites un flux brut venant de l'Internet (ou d'un truc du même genre, par exemple un lien NetBIOS).
En gros, tu as deux solutions:
-- utiliser une option au niveau des sockets pour traduire entre l'ASCII (extérieur) et l'EBCDIC (interne au programme), et alors tu peux garder ta solution avec '=' mais tu ne traites plus un flux brut, ce qui peux être un problème (par exemple si tu dois décoder du UTF-8 non signalé par ailleurs)
-- ne pas utiliser cette option, mais alors tu dois faire toi-même le décodage ASCII-EBCDIC en entrée; et à ce moment-là, tu vas te retrouver avec le pépin ci-dessus pour traiter le QP.
Évidemment, aucun des deux cas n'est vraiment optimum, il faut chercher le moindre mal. Je suis comme toi, je préfère et de très loin la première solution, mais je comprends qu'il y ait des cas où le seconde sera meilleure.
http://httpd.apache.org/docs/ebcdic.html est intéressant.
Antoine
Antoine Leca
En , Pierre Maurette va escriure:
#if '=' == 61
Marche pas. Dans la logique C, le préprocesseur est une chose, et le compilateur (et donc la machine cible) en est une autre. Et il se trouve qu'historiquement (et pour des raisons évidentes de simplicité), les préprocesseurs croisés font les opérations (évaluer les #if) dans leurs propres environnements, pas dans un environnement (simulé) de la cible. Idem pour les calculs en flottants au niveau du compilateur lui-même. Tout ceci est permis par la norme.
Donc si tu utilises un compilo croisé vers la machine EBCDIC, mais opérant sur une bécane Unix, tu va avoir '=' == 61 alors même que la cible est « caca ».
Antoine
En v2e3p0ld22i2t4c94t0q6ov6j42j62n3al@4ax.com, Pierre Maurette va escriure:
#if '=' == 61
Marche pas.
Dans la logique C, le préprocesseur est une chose, et le compilateur (et
donc la machine cible) en est une autre.
Et il se trouve qu'historiquement (et pour des raisons évidentes de
simplicité), les préprocesseurs croisés font les opérations (évaluer les
#if) dans leurs propres environnements, pas dans un environnement (simulé)
de la cible.
Idem pour les calculs en flottants au niveau du compilateur lui-même.
Tout ceci est permis par la norme.
Donc si tu utilises un compilo croisé vers la machine EBCDIC, mais opérant
sur une bécane Unix, tu va avoir '=' == 61 alors même que la cible est «
caca ».
Marche pas. Dans la logique C, le préprocesseur est une chose, et le compilateur (et donc la machine cible) en est une autre. Et il se trouve qu'historiquement (et pour des raisons évidentes de simplicité), les préprocesseurs croisés font les opérations (évaluer les #if) dans leurs propres environnements, pas dans un environnement (simulé) de la cible. Idem pour les calculs en flottants au niveau du compilateur lui-même. Tout ceci est permis par la norme.
Donc si tu utilises un compilo croisé vers la machine EBCDIC, mais opérant sur une bécane Unix, tu va avoir '=' == 61 alors même que la cible est « caca ».
