problème avec internationalisation, utf8, wchar_t

Le Thu, 21 Aug 2003 22:58:53 +0200, Vincent Richard a écrit :

L'encodage UTF-8 ne nécessite pas de caractères "larges" (wide char),
le texte est stocké dans des char* (c'est d'ailleurs pour ça que c'est
l'encodage choisi pour Unicode sous Linux).

donc rien à voir

Pour sortir un "Bonjour Benoît", il faut que tu entres le codage UTF-8
directement dans ton éditeur :

std::cout << "Bonjour Benoît" << std::endl;

très simple alors

Pour convertir sous Linux, avec iconv :

$ echo "Bonjour Benoît" | iconv -t utf-8 -f iso-8859-1

merci, je ne connaissais pas iconv :oD mais heureusement, il y a mule-ucs
pour emacs

Benoit Dejean <bnet@ifrance.com> wrote in message
news:<pan.2003.08.21.20.41.35.184528@ifrance.com>...

je m'appelle Benoît avec un i circonflexe et je me suis dit que ça
serait bien la mort si je n'arrivais pas à faire un programme qui
fasse "Bonjour Benoît"

je travaille uniquement en UTF-8 (sous GNU/Linux, locale -> fr_FR.UTF-8)

Sous Linux. Je suppose alors g++ (3.2.x ?).

si mon source est en UTF-8

cout << "Benoît";

fonctionne très bien, seulement, je ne pense pas que ça soit très
bien, si les locales de l'utilisateur sont différents.

Excellente reflection. En fait, le problème est plus complex que ça, et
ils entrent en jeu non seulement le ou les locales, mais les fonts
d'affichage, et comment le compilateur (et les autres programmes) les
gèrent.

alors je lis
vite et mal quelque chose sur les wchar_t et tente

wcout << "Benoît";

qui provoque un affichage défectueux (le i est absent -> "Benot"

j'essaye

wcout << L"Benoît";

qui mets en l'air mon wcout (fail) et qui affiche jusqu'à l'erreur "Beno"
puis !wcout

Il faut dire qu'en ce qui concerne g++, l'internationalisation n'est pas
son fort.

est ce que vous pouvez m'aider ou m'indiquer une lecture traitant de
ce genre de problème de localisation et de portabilité

La seule solution « correcte » et garantie par la norme serait :

std::wcout << L"Benou00EEt" ;

Ma version de g++ 3.2.2 donne une erreur : « `wcout' undeclared in
namespace `std' » -- sans doute une erreur de configuration quand je
l'ai générée, mais je ne trouve rien dans la documentation qui parle de
ça. Ma version de Sun CC (5.1) n'accepte pas les u, et quand j'essaie
avec un 'î', il compile, mais se bloque lors de l'execution.

Pour l'instant, la seule solution que j'ai trouvé, c'est de travailler
au bas niveau (<unistd.h>), et de réimplémenter tout moi-même. C'est un
peu triste à dire, mais il faut avouer que la norme ne vaut pas grand
chose pour la portabilité, étant donné que pratiquement tous les
compilateurs l'ignorent allégrement. À peu près la seule possibilité
d'avoir une implémentation de C++ à peu près conforme sous Linux, c'est
d'acheter le compilateur Comeau ($50), et la bibliothèque Dinkumware
($135). La même chose vaut malheureusement pour la plupart des systèmes
aujourd'hui -- c'est le cas au moins pour Solaris, par exemple, et je
crois aussi pour Windows.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Le Mon, 25 Aug 2003 04:20:18 -0700, kanz a écrit :

Benoit Dejean <bnet@ifrance.com> wrote in message
news:<pan.2003.08.21.20.41.35.184528@ifrance.com>...

je travaille uniquement en UTF-8 (sous GNU/Linux, locale ->
fr_FR.UTF-8)

Sous Linux. Je suppose alors g++ (3.2.x ?).

g++ 3.3.2 20030812

si mon source est en UTF-8

cout << "Benoît";

fonctionne très bien, seulement, je ne pense pas que ça soit très
bien, si les locales de l'utilisateur sont différents.

Excellente reflection. En fait, le problème est plus complex que ça,
et ils entrent en jeu non seulement le ou les locales, mais les fonts
d'affichage, et comment le compilateur (et les autres programmes) les
gèrent.

Il faut dire qu'en ce qui concerne g++, l'internationalisation n'est pas
son fort.

apparemment

est ce que vous pouvez m'aider ou m'indiquer une lecture traitant de ce
genre de problème de localisation et de portabilité

La seule solution « correcte » et garantie par la norme serait :

std::wcout << L"Benou00EEt" ;

pas facile à écrire

Pour l'instant, la seule solution que j'ai trouvé, c'est de travailler
au bas niveau (<unistd.h>), et de réimplémenter tout moi-même. C'est
un peu triste à dire, mais il faut avouer que la norme ne vaut pas
grand chose pour la portabilité, étant donné que pratiquement tous
les compilateurs l'ignorent allégrement.

je vais me tourner vers la Glib et les Gtk::ustring de Gtkmm. C'est
dommage je pensais que je pourrais résoudre simplement ce problème en
restant standard. Gtk (et gettext en plus) me fourniront sans doute tout
ce qu'il faut.

À peu près la seule possibilité
d'avoir une implémentation de C++ à peu près conforme sous Linux,
c'est d'acheter le compilateur Comeau ($50), et la bibliothèque
Dinkumware ($135).

Malheureusement, étant étudiant, je suis assez restreint au niveau
financier, mais je garde l'idée.

La même chose vaut malheureusement pour la plupart des systèmes
aujourd'hui -- c'est le cas au moins pour Solaris, par exemple, et je
crois aussi pour Windows.

Ne travaillant pas pas ces systèmes...

Mais si les locale et les w* ne peuvent pas m'aider à quoi servent les
locale et ces w* de la bibliothèque standard, si ce n'est le formatage
numérique?

kanze@gabi-soft.fr writes:

Benoit Dejean <bnet@ifrance.com> wrote in message
news:<pan.2003.08.21.20.41.35.184528@ifrance.com>...

je m'appelle Benoît avec un i circonflexe et je me suis dit que ça
serait bien la mort si je n'arrivais pas à faire un programme qui
fasse "Bonjour Benoît"

je travaille uniquement en UTF-8 (sous GNU/Linux, locale -> fr_FR.UTF-8)

Sous Linux. Je suppose alors g++ (3.2.x ?).

si mon source est en UTF-8

cout << "Benoît";

fonctionne très bien, seulement, je ne pense pas que ça soit très
bien, si les locales de l'utilisateur sont différents.

Excellente reflection. En fait, le problème est plus complex que ça,
et ils entrent en jeu non seulement le ou les locales, mais les
fonts d'affichage, et comment le compilateur (et les autres
programmes) les gèrent.

alors je lis vite et mal quelque chose sur les wchar_t et tente

wcout << "Benoît";

qui provoque un affichage défectueux (le i est absent -> "Benot"

j'essaye

wcout << L"Benoît";

qui mets en l'air mon wcout (fail) et qui affiche jusqu'à l'erreur "Beno"
puis !wcout

Il faut dire qu'en ce qui concerne g++, l'internationalisation n'est pas
son fort.

J'ai joué un peu avec g++ 3.3; et des variantes de:

#include <iostream>
#include <fstream>
#include <locale>

int main() {
std::locale::global(std::locale(""));
try {
std::wcout.imbue(std::locale());
} catch (std::exception& e) {
std::cerr << "std::exception on imbue() " << e.what() << std::endl;
} catch (...) {
std::cerr << "unknown exception on imbue()" << std::endl;
}
std::cerr << "Trying to wcout" << std::endl;
#ifdef USEOE
std::wcout << L"L'u0153uvre de Benou00EEtn" << std::endl;
#else
std::wcout << L"L'oeuvre de Benou00EEtn" << std::endl;
#endif
if (!std::wcout) {
std::cerr << "nwcout failedn" << std::endl;
std::wcout.clear();
std::wcout << std::endl;
}
{
std::cerr << "Trying to /dev/tty" << std::endl;
std::wofstream os("/dev/tty");
os.imbue(std::locale());
#ifdef USEOE
os << L"L'u0153uvre de Benou00EEtn" << std::endl;
#else
os << L"L'oeuvre de Benou00EEtn" << std::endl;
#endif
if (!os) {
std::cerr << "n/dev/tty failedn" << std::endl;
os.clear();
os << std::endl;
}
}
{
std::cerr << "Trying to file" << std::endl;
std::wofstream os("file");
os.imbue(std::locale());
#ifdef USEOE
os << L"L'u0153uvre de Benou00EEtnn" << std::endl;
#else
os << L"L'oeuvre de Benou00EEtn" << std::endl;
#endif
if (!os) {
std::cerr << "nfile failedn" << std::endl;
os.clear();
os << std::endl;
}
}
}

et en les faisant tourner dans des locales C, ISO-8851-1, ISO-8851-15,
UTF8. Le résultat est correct sauf en UTF8.

En UTF8, l'imbue sur wcout n'a pas l'air d'avoir d'effet (presque,
demander wcout.rdbuf()->getloc().name() a l'effet attendu mais la
stream foire sur le premier caractère hors ASCII). Sur /dev/tty et
sur fichier, ça se comporte de manière bizarre: il manque des
caractères (y compris le n) à la fin des lignes qui comportent des
caractères hors ASCII (et apparemment un caractère par caractère non
ASCII). Je n'ai pas ce comportement avec wprintf.

compilateurs l'ignorent allégrement. À peu près la seule possibilité
d'avoir une implémentation de C++ à peu près conforme sous Linux, c'est
d'acheter le compilateur Comeau ($50), et la bibliothèque Dinkumware
($135).

J'ai pas la bibliothèque de Dinkumware, et la libcomo n'est pas à la
hauteur sur ce point. J'ai même pas des résultats aussi bon qu'avec
gcc.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Benoit Dejean <bnet@ifrance.com> wrote in message
news:<pan.2003.08.25.14.14.20.144121@ifrance.com>...

La seule solution « correcte » et garantie par la norme serait :

std::wcout << L"Benou00EEt" ;

pas facile à écrire

Oui et non. Si tu as un clavier américain, il se peut que ce soit plus
facile à écrire que L"Benoît" (mais ça dépend de l'éditeur).

L'avantage, c'est que ça n'utilise que les caractères dans le jeu de
base, que tout compilateur est obligé à supporter. Et qui ne dépend pas
du locale courant.

Pour l'instant, la seule solution que j'ai trouvé, c'est de
travailler au bas niveau (<unistd.h>), et de réimplémenter tout
moi-même. C'est un peu triste à dire, mais il faut avouer que la
norme ne vaut pas grand chose pour la portabilité, étant donné que
pratiquement tous les compilateurs l'ignorent allégrement.

je vais me tourner vers la Glib et les Gtk::ustring de Gtkmm. C'est
dommage je pensais que je pourrais résoudre simplement ce problème en
restant standard. Gtk (et gettext en plus) me fourniront sans doute
tout ce qu'il faut.

Tu pourrais le résoudre en restant standard, SI tu trouves un
compilateur et une bibliothèque conforme. (Ici, c'est plutôt la
bibliothèque qui t'intéresse.)

À peu près la seule possibilité d'avoir une implémentation de C++ à
peu près conforme sous Linux, c'est d'acheter le compilateur Comeau
($50), et la bibliothèque Dinkumware ($135).

Malheureusement, étant étudiant, je suis assez restreint au niveau
financier, mais je garde l'idée.

Je comprends. Ce n'est vraiment pas cher, comparé aux prix des VC++ ou
des Sun CC, mais pour un étudiant, effectivement, c'est toujours
beaucoup.

La même chose vaut malheureusement pour la plupart des systèmes
aujourd'hui -- c'est le cas au moins pour Solaris, par exemple, et
je crois aussi pour Windows.

Ne travaillant pas pas ces systèmes...

C'était juste pour dire que tu n'es pas seul avec le problème:-).

Mais si les locale et les w* ne peuvent pas m'aider à quoi servent les
locale et ces w* de la bibliothèque standard, si ce n'est le formatage
numérique?

Les locales et les w* doivent pouvoir t'aider. Dans ton cas, la
bibliothèque standard permettrait à faire ce que tu veux.
Malheureusement, ton compilateur ne vient pas avec une bibliothèque
standard, mais seulement avec un sous-ensemble d'elle. De la même façon,
il n'implémente pas le langage standard, mais seulement un
sous-ensemble.

Si seulement ce n'était qu'un problème g++, je dirais tant pis.
Malheureusement, c'est le cas de prèsque tous les autres compilateurs
aussi. Ce qui fait que dans un certain sens, la norme n'est qu'une
feuille de papier, sans valeur réele:-(. (Et en fait, tu ne peux pas
écrire du C++ portable en te fiant à la norme.)

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Jean-Marc Bourguet <jm@bourguet.org> wrote in message
news:<usndib.b11.ln@news.bourguet.org>...

J'ai joué un peu avec g++ 3.3; et des variantes de:

#include <iostream>
#include <fstream>
#include <locale>

int main() {
std::locale::global(std::locale(""));
try {
std::wcout.imbue(std::locale());
} catch (std::exception& e) {
std::cerr << "std::exception on imbue() " << e.what() << std::endl;
} catch (...) {
std::cerr << "unknown exception on imbue()" << std::endl;
}
std::cerr << "Trying to wcout" << std::endl;
#ifdef USEOE
std::wcout << L"L'u0153uvre de Benou00EEtn" << std::endl;
#else
std::wcout << L"L'oeuvre de Benou00EEtn" << std::endl;
#endif
if (!std::wcout) {
std::cerr << "nwcout failedn" << std::endl;
std::wcout.clear();
std::wcout << std::endl;
}
{
std::cerr << "Trying to /dev/tty" << std::endl;
std::wofstream os("/dev/tty");
os.imbue(std::locale());
#ifdef USEOE
os << L"L'u0153uvre de Benou00EEtn" << std::endl;
#else
os << L"L'oeuvre de Benou00EEtn" << std::endl;
#endif
if (!os) {
std::cerr << "n/dev/tty failedn" << std::endl;
os.clear();
os << std::endl;
}
}
{
std::cerr << "Trying to file" << std::endl;
std::wofstream os("file");
os.imbue(std::locale());
#ifdef USEOE
os << L"L'u0153uvre de Benou00EEtnn" << std::endl;
#else
os << L"L'oeuvre de Benou00EEtn" << std::endl;
#endif
if (!os) {
std::cerr << "nfile failedn" << std::endl;
os.clear();
os << std::endl;
}
}
}

et en les faisant tourner dans des locales C, ISO-8851-1, ISO-8851-15,
UTF8. Le résultat est correct sauf en UTF8.

(Je suppose que les 8851 sont des typos pour 8859. ISO 8851 concerne la
beurre : détermination de la quantité d'eau, de graisse, etc.)

Avec USEOE définie, je suppose. Sinon, il n'y a aucune différence entre
8859-1 et 8859-15 dans ton exemple. Et les deux revient à simplement
faire tout de façon naïve, ce qu'a toujours fait g++ dans la passée.

Et quand tu parles de « résultat correct », ça veut dire quoi quand tu
sors u0153 en locale C, ou u00EE en locale C ou en locale ISO-8859-1.

Je sais qu'un des buts de g++, c'est un support complet et correct ici,
et qu'ils travaillent dur dessus, et je m'attends qu'il y a des
améliorations dans chaque version.

En UTF8, l'imbue sur wcout n'a pas l'air d'avoir d'effet (presque,
demander wcout.rdbuf()->getloc().name() a l'effet attendu mais la
stream foire sur le premier caractère hors ASCII).

C'est un des problèmes que j'ai constaté avec g++. Tu peux créer des
locales, utiliser imbue, etc., sans jamais avoir des exceptions, mais ça
continue à fonctionner comme si on était en locale "C" (au moins dans
les versions que j'ai -- je me précipite à installer 3.3.x).

Sur /dev/tty et sur fichier, ça se comporte de manière bizarre: il
manque des caractères (y compris le n) à la fin des lignes qui
comportent des caractères hors ASCII (et apparemment un caractère par
caractère non ASCII). Je n'ai pas ce comportement avec wprintf.

Je suppose (mais je suis loin d'être sûr) que wprintf en question est
celle de la bibliothèque système libc.{a,so}. Ça serait donc étonnant
qu'il ne fonctionne pas.

compilateurs l'ignorent allégrement. À peu près la seule possibilité
d'avoir une implémentation de C++ à peu près conforme sous Linux,
c'est d'acheter le compilateur Comeau ($50), et la bibliothèque
Dinkumware ($135).

J'ai pas la bibliothèque de Dinkumware, et la libcomo n'est pas à la
hauteur sur ce point. J'ai même pas des résultats aussi bon qu'avec
gcc.

La libcomo est assez nouveau, et effectivement n'est pas encore à la
hauteur. Et vue qu'ici, il s'agit surtout d'un problème de
bibliothèque...

Moi-même, je n'ai pas la bibliothèque Dinkumware non plus. Mais dans la
passée (il y a quatre ou cinq ans), je me suis servi de VC++, qui
l'utilise, et les locales y fonctionnaient bien, déjà alors.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

kanze@gabi-soft.fr writes:

Benoit Dejean <bnet@ifrance.com> wrote in message
news:<pan.2003.08.25.14.14.20.144121@ifrance.com>...

La seule solution « correcte » et garantie par la norme serait :

std::wcout << L"Benou00EEt" ;

pas facile à écrire

Oui et non. Si tu as un clavier américain, il se peut que ce soit plus
facile à écrire que L"Benoît" (mais ça dépend de l'éditeur).

recode utf8..java

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet <jm@bourguet.org> writes:

kanze@gabi-soft.fr writes:

(Je suppose que les 8851 sont des typos pour 8859. ISO 8851 concerne la
beurre : détermination de la quantité d'eau, de graisse, etc.)

Exact (du moins sur la typo, j'ai pas été vérifier ce que concernait
ISO 8851).

Avec USEOE définie, je suppose. Sinon, il n'y a aucune différence
entre 8859-1 et 8859-15 dans ton exemple. Et les deux revient à
simplement faire tout de façon naïve, ce qu'a toujours fait g++ dans
la passée.

Et quand tu parles de « résultat correct », ça veut dire quoi quand tu
sors u0153 en locale C, ou u00EE en locale C ou en locale ISO-8859-1.

fail() retourne true. Tu t'attendais à quoi?

Pour info, bug 12062 pour g++.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

le Mardi 26 Août 2003 10:13, kanze@gabi-soft.fr écrivit :

std::wcout << L"Benou00EEt" ;

pas facile à écrire

Oui et non. Si tu as un clavier américain, il se peut que ce soit plus
facile à écrire que L"Benoît" (mais ça dépend de l'éditeur).

si l'éditeur est à l'heure d'unicode, ça dépendra plus des méthodes d'input
fournies par la plateforme que de l'éditeur lui-même..

L'avantage, c'est que ça n'utilise que les caractères dans le jeu de
base, que tout compilateur est obligé à supporter.

Obligé de supporter, oui, mais pas de comprendre tel quel dans un fichier.
Je viens de jeter un oeil au §2.1 de la norme,
"Physical source file characters are mapped, in an implementation-defined
manner, to the basic source character set."

J'ai la nette impression que ça implique qu'aucun "physical source file"
n'est garanti de compiler par toutes les implémentations, même si il ne
contient que des caractères ASCII.

On imagine mal une implémentation choisir de mapper les membres du 'basic
character source set' (qui font partie des caractères ASCII) autrement que
par la fonction identité, et c'est donc probablement une supposition
légitime implicitement faite par tout le monde, mais j'ai l'impression
qu'en fait, même ça n'est pas garanti.

Et qui ne dépend pas
du locale courant.

effectivement, et à mon avis c'est bien parceque les caractères ASCII sont
encodés partout pareil, indépendamment de la plateforme et de la locale,
qu'on peut raisonnablement supposer qu'un fichier en ASCII sera
convenablement mappé par toutes les implémentations.

Mais le jour où UTF-8 sera enfin bien en place, on pourra faire la même
supposition de fichiers encodés en UTF-8.
(il restera sûrement des plateformes non-UTF-8 pendant des dizaines
d'années, mais il est très facile de convertir un fichier source codé en
UTF-8 vers le 'basic source character set' avec les universal character
names, donc je vois pas pourquoi on ne conviendrait pas, à terme, de
choisir UTF-8 comme l'encodage 'implicite' des fichiers sources)

enfin bref, d'ici qques années, je pense qu'on pourra taper sans risque dans
un source C++
std::wcout << L"l'½uvre de benoît"

, directement en UTF-8 (bon, dans ce msg c'est en iso-8859-15 car le forum
rejette les message en UTF-8, mais il faut imaginer le e-mêlé dans le source
codé en UTF-8 sur 2 octets, 0xC5 0x93)

ou
std::cout << "l'½uvre de benoît"

Dans un narrow string literal, les caractères étendus sont transformés en
universal-character-name, et
alors, d'après §2.13.4,
"In a narrow string literal, a universal-character-name may map to more than
one char element due to multibyte encoding".
Ca autorise donc un compilo à encoder les caractères étendus des 'narrow
string literal' par UTF-8 (i.e. de les laisser tel quel si le fichier lu
est en UTF-8), et comme c'est la meilleure chose à faire, il serait
raisonnable d'attendre du compilo qu'il se comporte ainsi.


enfin bref, UTF-8 est conçu pour pouvoir devenir le nouveau codage implicite
des caractères, supersedant sans douleur l'ASCII, alors on peut tout de
même esperer que ça finisse par se faire.
je sais pas où en sont les principaux compilos pour traiter correctement les
chaînes UTF-8 dans le source, mais je parierais que d'ici qques années ils
supporteront psans problème un encodage UTF-8 des sources.
(si le fichier est ASCII, ca marche aussi bien, si il est en iso-8859-truc
avec des caractères étendus il y a peu de chance que ça forme une séquence
UTF-8 valide, et le compilo peut donc deviner un encodage autre que UTF-8,
par exemple prendre celui de la locale en cours - et si c'est UTF-8 il ne
lui reste plus qu'à choisir un iso-8859-XX par divination, ou question à
l'utilisateur.. )

-- Sam
Enlever les mots en trop dans mon e-mail pour répondre

Samuel Krempp <krempp@crans.trucs.en.trop.org> writes:

On imagine mal une implémentation choisir de mapper les membres du
'basic character source set' (qui font partie des caractères ASCII)
autrement que par la fonction identité, et c'est donc probablement
une supposition légitime implicitement faite par tout le monde, mais
j'ai l'impression qu'en fait, même ça n'est pas garanti.

Tu peux avoir une implémentation qui désire que ton fichier soit codé
en EBCDIC.

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org