[J'espère pas trop HS] Portabilité et carctères accentués

In 'fr.comp.lang.c', Noé Falzon <noe.falzonPASDEPUB@tiscali.fr> wrote:

je suis en train de coder un petit logiciel en C, fonctionnant dans une
console. Je dispose de deux UNIX : un Mac sous OS X, et un Linux (Yellow
Dog) sur une autre machine.
J'ai remarqué (à mon grand dam :) ) que les caractères accentués des
sources écrites sur le premier ne passent pas quand je les lis sur le
second.
Je suppose que cela serait aussi le cas si je lisais les sources sous
Windows.

Je me demandais donc si dans le C standard, il y avait un moyen d'écrire
"universellement" un caractère donné, de sorte que chaque compilateur y
associe un code ASCII correspondant à la plateforme sur laquelle il
tourne.

Non, tout simplement parce que le codage ASCII ne concerne que les caractères
non accentués (0-127). Pour les autres, c'est la jungle. Disons que le
charset "iso-8859-1" est assez courant...

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Noé Falzon wrote:

Bonjour,

Bonjour,

je suis en train de coder un petit logiciel en C, fonctionnant dans une
console. Je dispose de deux UNIX : un Mac sous OS X, et un Linux (Yellow
Dog) sur une autre machine.
J'ai remarqué (à mon grand dam :) ) que les caractères accentués des
sources écrites sur le premier ne passent pas quand je les lis sur le
second.

Le C n'assure rien (à ma connaissance) tant que l'on sort des caractères
normaux du jeu de caractère ASCII, c'est à dire de 0 à 127.

<HS>
Cependant, entre un mac et un linux, ca ne devrait pas poser de problèmes !
Je suppose que les deux unix sont sur le même charset par défaut, c'est à
dire ISO8859-1 donc je ne vois pas pourquoi ca ferait ceci. Peut etre
est-ce du à l'éditeur, mais linux et mac ayant des éditeurs en commun
(emacs par exemple) en utilisant l'un de ceux ci ca ne devrait pas etre
génant.
De plus c'est compilé je suppose avec le même compilateur (gcc) qui est
commun aux deux et interprete donc les sources de la même manière. Ca ne
peut donc venir que de l'éditeur, ou de la console. Voir donc l'encodage
des caractères sur chaque machines.
</HS>

Anthony
--
"You could be my unintended, choice to live my life extended
You should be the one I'll always love, I'll be there as soon as I can
But I'm busy mending broken pieces of the life I had before"
(C) Muse - Unintended

Je me demandais donc si dans le C standard, il y avait un moyen d'écrire
"universellement" un caractère donné, de sorte que chaque compilateur y
associe un code ASCII correspondant à la plateforme sur laquelle il
tourne.

sous OS X, tu peux changer le réglage du terminal pour qu'il
affiche du iso-8859-1.

--
DINH V. Hoa,

"dans la famille, on est tous intelligents" -- sunZ

Emmanuel Delahaye wrote:

In 'fr.comp.lang.c', Noé Falzon <noe.falzonPASDEPUB@tiscali.fr> wrote:

je suis en train de coder un petit logiciel en C, fonctionnant dans une
console. Je dispose de deux UNIX : un Mac sous OS X, et un Linux (Yellow
Dog) sur une autre machine.
J'ai remarqué (à mon grand dam :) ) que les caractères accentués des
sources écrites sur le premier ne passent pas quand je les lis sur le
second.
Je suppose que cela serait aussi le cas si je lisais les sources sous
Windows.

Je me demandais donc si dans le C standard, il y avait un moyen d'écrire
"universellement" un caractère donné, de sorte que chaque compilateur y
associe un code ASCII correspondant à la plateforme sur laquelle il
tourne.

Non, tout simplement parce que le codage ASCII ne concerne que les caractères
non accentués (0-127). Pour les autres, c'est la jungle. Disons que le
charset "iso-8859-1" est assez courant...

Se pose la question connexe de: "Quels sont les character encoding

autorises dans un source C par la norme?" La reponse se trouve dans
5.2.1 et ne mentionne que des character sets, independement de leur
encoding.

En consequence, et pour repondre a la question de Noe, je recommande
UTF-8 ou un autres character encoding prevu pour encoder Unicode, et
d'utiliser des editeurs qui comprennent UTF-8. C'est un peu dans
l'esprit "marteau-pilon pour ecraser une mouche", mais ca garantit la
meilleure portabilite (theorique) pour le source.

Bien entendu, de ce cote-ci de l'hemisphere, iso-8859-1 garantit en
pratique une portabilite similaire.

--
Bertrand Mollinier Toublet
"Reality exists" - Richard Heathfield, 1 July 2003

En noe.falzonPASDEPUB-91E71A.12110220052004@news9-e.proxad.net, Noé Falzon
va escriure:

Je me demandais donc si dans le C standard, il y avait un moyen
d'écrire "universellement" un caractère donné, de sorte que chaque
compilateur y associe un code ASCII correspondant à la plateforme sur
laquelle il tourne.

Oui. Il faut écrire u, suivi de 4 caractères hexa (exactement 4) qui donne
le code Unicode du caractère. C'est un truc inventé vers 1995 pour Java, et
cela fait partie des normes C++:1998 et C:1999. Cela est même sensé marcher
dans les identificateurs.

Cela dit, il ne faut pas se faire d'illusions: les compilateurs C ou C++
répandus actuels, et particulièrement GCC, n'en ont cure et ignore
joyeusement cette particularité, arguant que « ils n'ont pas moyen de
connaître le jeu de caractère en cours ».

Autrement, cela existe depuis plusieurs années, mais tu ne peux pas en tirer
partie en 2004. Bientôt, quand toutes les machines et tous les OS
travailleront en Unicode, c'est-à-dire quand tu n'en auras plus besoin, tu
pourra l'utiliser.


Antoine

In article <2h437tF8ttgrU1@uni-berlin.de>,
Bertrand Mollinier Toublet
<bertrand.mollinierNOSPAMtoublet@enst-bretagne.fr> wrote:

En consequence, et pour repondre a la question de Noe, je recommande
UTF-8 ou un autres character encoding prevu pour encoder Unicode, et
d'utiliser des editeurs qui comprennent UTF-8. C'est un peu dans
l'esprit "marteau-pilon pour ecraser une mouche", mais ca garantit la
meilleure portabilite (theorique) pour le source.

Bien entendu, de ce cote-ci de l'hemisphere, iso-8859-1 garantit en
pratique une portabilite similaire.

Je vais essayer ça. Mais le compilateur saura reconnaitre tout seul
l'encodage ? Parce qu'à la limite, au niveau de l'édition, c'est juste
assez désagréable. Mais il faudrait que le compilo y arrive.

Je vais faire des tests, maintenant que j'en sais plus.

Merci à vous pour vos réponses,
Noé Falzon
--
"Je ne deteste que les bourreaux" -- Albert Camus

Pour m'écrire un mail, veuillez retirer PASDEPUB de mon adresse ;)

In 'fr.comp.lang.c', Noé Falzon <noe.falzonPASDEPUB@tiscali.fr>
wrote:

je suis en train de coder un petit logiciel en C, fonctionnant dans
une console. Je dispose de deux UNIX : un Mac sous OS X, et un
Linux (Yellow Dog) sur une autre machine.

Est-ce que les paramètres de configuration des jeux de caractères sont les
mêmes sur les deux machines ? (LANG, LC_CTYPE, voire LC_ALL si par erreur il
serait positionné)

J'ai remarqué (à mon grand dam :) ) que les caractères accentués des
sources écrites sur le premier ne passent pas quand je les lis sur
le second.
Je suppose que cela serait aussi le cas si je lisais les sources
sous Windows.

Tu devrais vérifier avant de faire ce genre de supposition (qui n'apporte
rien à l'affaire) en public.

Je me demandais donc si dans le C standard, il y avait un moyen
d'écrire "universellement" un caractère donné, de sorte que chaque
compilateur y associe un code ASCII correspondant à la plateforme
sur laquelle il tourne.

ASCII n'est pas le bon terme ici. Par définition, les caractères accentués
sont en dehors de l'ASCII. C'est bien tout le problème d'ailleurs.

De plus, (en général) le compilateur ne fait absolument rien: il se contente
de recopier bêtement les caractères depuis les chaînes de caractères du
source directement dans les données du binaire exécutable. Directement du
producteur au consommateur ! D'où mes questions ci-dessus sur les
paramétrages.



En 2h437tF8ttgrU1@uni-berlin.de, Bertrand Mollinier Toublet va escriure:

Emmanuel Delahaye wrote:

Non, tout simplement parce que le codage ASCII ne concerne que les
caractères non accentués (0-127). Pour les autres, c'est la jungle.
Disons que le charset "iso-8859-1" est assez courant...

Se pose la question connexe de: "Quels sont les character encoding

autorises dans un source C par la norme?" La reponse se trouve dans
5.2.1 et ne mentionne que des character sets, independement de leur
encoding.

Voui. Mais si tu regardes dans la norme, tu vas voir les distinctions
byzantines entre caractères du jeu de base et du jeu étendu, les NUC, etc.
Autrement dit, ce n'est pas là que tu vas trouver une réponse, mais dans la
pratique.

En consequence, et pour repondre a la question de Noe, je recommande
UTF-8 ou un autres character encoding prevu pour encoder Unicode, et
d'utiliser des editeurs qui comprennent UTF-8.

Là, tu vas aussi obliger Noé, *et* les utilisateurs de son ou ses
programmes, à tous passer en UTF-8 sur leur terminal. Est-ce un bien ?

<HS>
Et là pour le coup, c'est sûr que pour Windows c'est mort: Windows n'accepte
pas facilement UTF-8 en console, seulement le jeu Windows proche de
iso-8859-1, le jeu DOS et avec NT UTF-16; mais pour lui faire manger du
UTF-8, bonjour la galère... et adieu toute portabilité.
</HS>

C'est un peu dans
l'esprit "marteau-pilon pour ecraser une mouche", mais ca garantit la
meilleure portabilite (theorique) pour le source.

Et aussi une nettement moins bonne portabilité pour l'exécutable, au moins
dans l'immédiat.
Bien sûr, si tout le monde se mettait à faire cela, et à réclamer aux
éditeurs de compilateurs qu'ils prennent en compte cela, peut-être que les
choses avanceraient. Mais mon impression en ce moment, au moins dans les
mondes *nix et Windows que je connais, c'est que cela n'en prend pas le
chemin (dans le monde des mainframes IBM, par contre, à cause de EBCDIC et
des problèmes monstrueux qui en dérivent, c'est acquis depuis longtemps;
certains pensent d'ailleurs que c'est la preuve qu'il ne faut pas faire
cela, ce qui leur donne des raisons pour ne *rien* faire; joli
raisonnement).


<SPECIAL pour="Galerie">

Bien entendu, de ce cote-ci de l'hemisphere,

De l'autre côté, c'est où ? Vers le centre de la terre ? les troglodytes
parlent autre chose ou encodent autrement que ceux qui vivent à la surface ?

;-)
</SPECIAL>


Antoine

Anthony Fleury <fleury_anthony@_hotmail_.com> wrote in message
news:<40aca61c$0$25118$626a14ce@news.free.fr>...

Noé Falzon wrote:

je suis en train de coder un petit logiciel en C, fonctionnant dans
une console. Je dispose de deux UNIX : un Mac sous OS X, et un Linux
(Yellow Dog) sur une autre machine. J'ai remarqué (à mon grand dam
:) ) que les caractères accentués des sources écrites sur le premier
ne passent pas quand je les lis sur le second.

Le C n'assure rien (à ma connaissance) tant que l'on sort des
caractères normaux du jeu de caractère ASCII, c'est à dire de 0 à 127.

Même pas. Le C n'assure que ce que les caractères dits de base existe
dans le locale "C", et que dans ce locale, ils s'encodent avec des
valeurs positives. Il n'assure rien en ce qui concerne l'encodage.

En fait, il y a toujours plusieurs choses qui entrent en jeu: les
différents locales et les fonts dont l'application se sert sont les deux
principaux. Typiquement, si les fonts qui servent sur les deux machines
implémentent le même encodage, les caractères apparaissent identiques
quand on régarde le texte. (Attention : on peut avoir les mêmes fonts
sur l'écran, et des fonts différents sur l'imprimante.) En revanche,
pour déterminer si un caractère est majuscule, etc., c'est le locale qui
compte. Si l'encodage précisé par le locale (ou plus particulièrement,
par la catégorie LC_CTYPE du locale) n'est pas le même que celui du font
utilisé, les résultats peuvent être, disons intéressants.

Typiquement, les caractères accentués dans les commentaires et dans les
chaînes de caractères seront passé jusqu'à l'application sans
transcodage. En ce qui concerne les caractères accentués dans les
symboles, je ne sais même pas si gcc les a déjà implémentés.

<HS>
Cependant, entre un mac et un linux, ca ne devrait pas poser de
problèmes ! Je suppose que les deux unix sont sur le même charset par
défaut,

Voir ci-dessus. Ce qui vaut en général vaut aussi ici pour Unix et ses
semblables.

Sous X, on peut utiliser xfontsel, .Xdefaults et l'option -fn pour
trouver, puis choisir le font qui convient. Avec xfontsel, ce sont les
deux dernières colonnes -- rgstry et encdng -- qui concerne l'encodage
du font.

Mais autant que je sache, le Mac est l'exception parmi les Unix, et ne
se sert pas de X. N'empêche qu'il doit y avoir des outils semblable,
quelque chose pour dire à une application de quel font il faut s'en
servir.

c'est à dire ISO8859-1

Je crois que le defaut sous Linux est UTF-8. Je ne suis pas sûr ; parce
que je transfère pas mal de fichiers entre les systèmes, et que mes
imprimants ont tous des fonts ISO 8859-1, je ai bien configuré
(exprès) mon Linux pour utiliser cet encodage. Dans mon utilisateur,
évidemment ; c'est clair que rien n'exige que tous les utilisateurs
aient la même configuration.

donc je ne vois pas pourquoi ca ferait ceci. Peut etre est-ce du à
l'éditeur, mais linux et mac ayant des éditeurs en commun (emacs par
exemple) en utilisant l'un de ceux ci ca ne devrait pas etre génant.

L'éditeur (au moins emacs) dépend de l'environement ; pendant longtemps,
j'ai un comportement différents sous Linux et sous Solaris pour des
commandes comme aller au mot prochain (qui a priori utilise
l'environement pour déterminer ce qui est blanc et ce qui ne l'est pas),
bien que j'affichais tout correctement.

De plus c'est compilé je suppose avec le même compilateur (gcc) qui
est commun aux deux et interprete donc les sources de la même
manière. Ca ne peut donc venir que de l'éditeur, ou de la
console. Voir donc l'encodage des caractères sur chaque machines.

Il n'y a pas d'encodage fixe pour la machine. L'encodage dépend de
l'environement à un moment donné, et je n'ai pas le moindre problème
sous Linux à avoir des encodages différents dans de différentes
fenêtres.

</HS>

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

En d6652001.0405210534.4045fdab@posting.google.com, James Kanze va escriure:
: Anthony Fleury wrote in message
news:<40aca61c$0$25118$626a14ce@news.free.fr>...
:> Le C n'assure rien (à ma connaissance) tant que l'on sort des
:> caractères normaux du jeu de caractère ASCII, c'est à dire de 0 à
:> 127.
:
: Même pas. Le C n'assure que ce que les caractères dits de base existe
: dans le locale "C", et que dans ce locale, ils s'encodent avec des
^^^^^^^^^^^^^^^^^^
: valeurs positives.

Ailleurs aussi. Les valeurs (pour le jeu de base) ne changent jamais entre
les locales. C'est ce qui permet d'utiliser 'a', même si tu changes de
locale. Sinon, tu ne pourrais même pas utiliser cette notation.

Ce qui n'est pas garanti, c'est que les caractères du jeu de base soit
imprimable...


Antoine

"Antoine Leca" <root@localhost.gov> writes:

|> >> In 'fr.comp.lang.c', Noé Falzon <noe.falzonPASDEPUB@tiscali.fr>
|> >> wrote:
|> >>> je suis en train de coder un petit logiciel en C, fonctionnant
|> >>> dans une console. Je dispose de deux UNIX : un Mac sous OS X, et
|> >>> un Linux (Yellow Dog) sur une autre machine.

|> Est-ce que les paramètres de configuration des jeux de
|> caractères sont les mêmes sur les deux machines ? (LANG,
|> LC_CTYPE, voire LC_ALL si par erreur il serait positionné)

|> >>> J'ai remarqué (à mon grand dam :) ) que les caractères
|> >>> accentués des sources écrites sur le premier ne passent
|> >>> pas quand je les lis sur le second. Je suppose que cela serait
|> >>> aussi le cas si je lisais les sources sous Windows.

|> Tu devrais vérifier avant de faire ce genre de supposition (qui
|> n'apporte rien à l'affaire) en public.

Si déjà une autre machine Unix a des problèmes à lire ses
caractères, il n'y a pas de raison à supposer que Windows y
arrive:-). En fait, c'est tout une question d'encodage ; Windows, comme
la plupart des Unix, en comprend plusieurs, et a un défaut, qui n'est
pas nécessairement le même qu'un système Unix donné.

|> >>> Je me demandais donc si dans le C standard, il y avait un moyen
|> >>> d'écrire "universellement" un caractère donné, de sorte
|> >>> que chaque compilateur y associe un code ASCII correspondant
|> >>> à la plateforme sur laquelle il tourne.

|> ASCII n'est pas le bon terme ici. Par définition, les
|> caractères accentués sont en dehors de l'ASCII. C'est bien
|> tout le problème d'ailleurs.

|> De plus, (en général) le compilateur ne fait absolument rien:
|> il se contente de recopier bêtement les caractères depuis les
|> chaînes de caractères du source directement dans les
|> données du binaire exécutable. Directement du producteur au
|> consommateur ! D'où mes questions ci-dessus sur les
|> paramétrages.

Le tout, c'est d'abord comprend ce qu'il fait avec ces caractères.
J'en vois trois utilisations :

- Seulement dans les commentaires. Ce que tu dis est certainement
vrai@; une fois dans un commentaire, la seule chose qui intéresse
le compilateur, c'est un "*/", ou un 'n', pour le cas des
commentaires "//" en C99.

- Dans les chaînes constantes et les constantes de caractère.
Là, c'est moins évident, surtout s'il s'agit d'un
cross-compiler, mais c'est souvent le cas. Selon la norme, si on
veut être certain d'avoir des é, par exemple, il faudrait
écrire 'u00E9'. Mais ça suppose un compilateur conforme à
C99, ce qui n'est pas donné.

- Dans les symboles. Je sais que C99 dit que c'est permis, mais le
nombre de compilateurs qui le supporte me semble assez reduit.

|> En 2h437tF8ttgrU1@uni-berlin.de, Bertrand Mollinier Toublet va
|> escriure:
|> > Emmanuel Delahaye wrote:

|> >> Non, tout simplement parce que le codage ASCII ne concerne que
|> >> les caractères non accentués (0-127). Pour les autres,
|> >> c'est la jungle. Disons que le charset "iso-8859-1" est assez
|> >> courant...

|> > Se pose la question connexe de: "Quels sont les character encoding
|> > autorises dans un source C par la norme?" La reponse se trouve
|> > dans 5.2.1 et ne mentionne que des character sets, independement
|> > de leur encoding.

|> Voui. Mais si tu regardes dans la norme, tu vas voir les
|> distinctions byzantines entre caractères du jeu de base et du jeu
|> étendu, les NUC, etc. Autrement dit, ce n'est pas là que tu
|> vas trouver une réponse, mais dans la pratique.

En fait, la norme n'exige pas grand chose en ce qui concerne ce qui est
présent. À peu près tout ce qu'elle dit, c'est comment le faire
SI on décide à l'offrir. Et encore, c'est très ouvert.

Le problème, en fin de compte, c'est que dans ton fichier source, tu
as un octet avec la valeur 0xE9 (par exemple). Or, ce que tu vas voir
sur l'écran dépend de l'encodage de la police de caractères qui
sert à l'afficher. Et là, le compilateur C n'a pas grand chose
à faire ou à voir. Il est rélativement trivial sous X, par
exemple, d'arriver à faire un cat du même fichier dans deux xterm
distincts, et de voir deux choses différentes. Et il est même
assez fréquent de voir une chose quand tu fais un cat, une autre dans
l'éditeur, et encore une troisième quand tu imprimes le fichier.
Alors, laquelle est correcte, ou plutôt, qu'est-ce que le compilateur
C doit faire.

Comme j'ai dit, dans le commentaire, ce n'est probablement pas un
problème; les codes de '*'. '/' et 'n' sont les mêmes dans tous
les encodages courants. Et c'est tout ce qui intéresse au
compilateur. Alors, au moins de lui filer de l'EBCDIC.

En ce qui concerne les caractères dans les constantes (de chaîne
et de caractère), la situation est un peu plus complex. La norme C
dit que le compilateur traduira de l'encodage source en l'encodage
execution. Seulement voilà, sur la plupart des systèmes (au moins,
sous MS-Windows ou sous X), l'encodage est un caractèristique
dynamique, qui peut varier selon l'outil -- c'est les codepage de
Windows, et l'option -fn sous X. Alors, en ce qui concerne l'encodate
source, rien ne prouve que l'encodage que voit le compilateur soit le
même qui a servi à l'éditeur lors du saisi. Et quant à
l'execution, comme j'ai dit, ça dépend de la fenêtre où tu
lances l'application. En fin de compte, la plupart, sinon tous, les
compilateurs prenent la solution de la facilité ; ils supposent que
l'encodage de l'execution est celui qui a servi lors de l'édition du
fichier source.

Alors, il faut une solution pragmatique. S'il ne s'agit que d'afficher
quelques textes constante en français, la solution la plus portable,
c'est de supposer ou ISO 8859-1 ou ISO 8859-15, et se limiter au
sous-ensemble commun (qui ne suffit pas, puisqu'il ne ne contient ni le
oe, ni l'euro, mais c'est la vie). C'est loins d'être partaite comme
solution, mais ça marche, et c'est suffisamment bien pour beaucoup
d'applications.

|> > En consequence, et pour repondre a la question de Noe, je
|> > recommande UTF-8 ou un autres character encoding prevu pour
|> > encoder Unicode, et d'utiliser des editeurs qui comprennent UTF-8.

|> Là, tu vas aussi obliger Noé, *et* les utilisateurs de son ou
|> ses programmes, à tous passer en UTF-8 sur leur terminal. Est-ce
|> un bien ?

Est-ce même possible ?

|> <HS>
|> Et là pour le coup, c'est sûr que pour Windows c'est mort:
|> Windows n'accepte pas facilement UTF-8 en console, seulement le jeu
|> Windows proche de iso-8859-1, le jeu DOS et avec NT UTF-16; mais
|> pour lui faire manger du UTF-8, bonjour la galère... et adieu
|> toute portabilité.
|> </HS>

Il existe certainement des utilitaires de transcodage. Après tout,
UTF-8 est l'encodage de l'Internet. Mais c'est sûr qu'utiliser UTF-8
sous Windows n'est pas gagné d'avance.

C'est moins vrai sous la plupart des Unix, mais ce n'est pas forcement
ce qu'il y a de plus facile non plus. Le tout dépend de ce que
l'utilisateur a installé comme jeux de caractères et de locales.

|> > C'est un peu dans l'esprit "marteau-pilon pour ecraser une
|> > mouche", mais ca garantit la meilleure portabilite (theorique)
|> > pour le source.

|> Et aussi une nettement moins bonne portabilité pour
|> l'exécutable, au moins dans l'immédiat.

En ce qui concerne les comentaires, ce n'est ni plus ni moins portable
que quelque chose d'autres, même pour les sources. En ce qui concerne
les constantes de chaîne et de caractère, l'utilisation de UTF-8
exclut l'utilisation sous Windows, et le rend plus difficile que
nécessaire sous la plupart de Unix.

|> Bien sûr, si tout le monde se mettait à faire cela, et à
|> réclamer aux éditeurs de compilateurs qu'ils prennent en
|> compte cela, peut-être que les choses avanceraient.

|> Mais mon impression en ce moment, au moins dans les mondes *nix et
|> Windows que je connais, c'est que cela n'en prend pas le chemin
|> (dans le monde des mainframes IBM, par contre, à cause de EBCDIC
|> et des problèmes monstrueux qui en dérivent, c'est acquis
|> depuis longtemps; certains pensent d'ailleurs que c'est la preuve
|> qu'il ne faut pas faire cela, ce qui leur donne des raisons pour ne
|> *rien* faire; joli raisonnement).

Une partie du problème, c'est sûrement qu'on ne sait pas
exactement ce qu'il faut faire. Le problème, c'est que le
caractère que voit l'utilisateur du programme (et en fin de compte,
c'est ça qui compte, je crois) dépend de trop de facteurs en
dehors du contrôle du compilateur.

Java s'est adressé au problème de façon beaucoup plus
sérieusement. Avec le résultat qu'ils ont une sacrée machine
à gaz, et que ça ne marche pas toujours mieux -- le programmeur a
une maîtrise beaucoup plus précise de l'encodage de ses sorties,
mais il n'a toujours aucun moyen de savoir l'encodage de la police qui
sert à l'affichage.

Et comment faire autrement ? Tu écris du texte dans un fichier.
L'utilisateur affiche le fichier sur l'écran, au moyen de cat, et
c'est du UTF-8 ; il le balance vers l'imprimante, avec lpr, et c'est du
ISO 8859-1.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34