J'ai essayé ça :
std::wofstream file("C:/test.txt");
file.imbue(std::locale("UTF-8"));
file << (wchar_t)0x732b;
mais le constructeur de std::locale lance une exception.
Est-ce mon système (VC++6) qui n'a pas de locale UTF-8 ou
est-ce que j'utilise pas std::locale de la bonne façon ?
J'ai essayé ça :
std::wofstream file("C:/test.txt");
file.imbue(std::locale("UTF-8"));
file << (wchar_t)0x732b;
mais le constructeur de std::locale lance une exception.
Est-ce mon système (VC++6) qui n'a pas de locale UTF-8 ou
est-ce que j'utilise pas std::locale de la bonne façon ?
J'ai essayé ça :
std::wofstream file("C:/test.txt");
file.imbue(std::locale("UTF-8"));
file << (wchar_t)0x732b;
mais le constructeur de std::locale lance une exception.
Est-ce mon système (VC++6) qui n'a pas de locale UTF-8 ou
est-ce que j'utilise pas std::locale de la bonne façon ?
Les conventions du nommage des locales dépendent du système,
mais a priori, le nom d'un locale doit spécifier à la fois la
langue, l'endroit géographique, et l'encodage. Chez moi, par
exemple (mais c'est Solaris, non Windows), j'ai « en_US.UTF-8 ».
A priori, il y aurait aussi un « fr_FR.UTF-8 », mais ce n'est
pas installé.
Malheureusement, non seulement il n'y a pas de normalisation en
ce qui concerne les noms, il n'y a pas non plus de moyen
portable pour déterminer quels locales sont disponibles.
Les conventions du nommage des locales dépendent du système,
mais a priori, le nom d'un locale doit spécifier à la fois la
langue, l'endroit géographique, et l'encodage. Chez moi, par
exemple (mais c'est Solaris, non Windows), j'ai « en_US.UTF-8 ».
A priori, il y aurait aussi un « fr_FR.UTF-8 », mais ce n'est
pas installé.
Malheureusement, non seulement il n'y a pas de normalisation en
ce qui concerne les noms, il n'y a pas non plus de moyen
portable pour déterminer quels locales sont disponibles.
Les conventions du nommage des locales dépendent du système,
mais a priori, le nom d'un locale doit spécifier à la fois la
langue, l'endroit géographique, et l'encodage. Chez moi, par
exemple (mais c'est Solaris, non Windows), j'ai « en_US.UTF-8 ».
A priori, il y aurait aussi un « fr_FR.UTF-8 », mais ce n'est
pas installé.
Malheureusement, non seulement il n'y a pas de normalisation en
ce qui concerne les noms, il n'y a pas non plus de moyen
portable pour déterminer quels locales sont disponibles.
file << L"à";
file << L"à";
file << L"à";
le Wednesday 20 April 2005 19:02, écrivit :file << L"à";
je suis peut-être à coté de la plaque, mais je me méfie de ce
que fait le compilateur des caractères non-ascii, je ferais
plutôt des tests en tapant un caractere d'une façon standard :
uC3A0
(ça devrait être 'à', à moins que je me sois gouré dans mes
codes..)
bon, je dis pas que ça va forcément changer qque chose, mais
au moins ça évite d'ajouter d'éventuels problèmes
d'interpretation du caractère par le compilateur.
D'ailleurs, si on veut mettre des caractères non ascii dans un
source, le seul moyen portable est de tous les traduire en
"universal character name", non ?
le Wednesday 20 April 2005 19:02, écrivit :
file << L"à";
je suis peut-être à coté de la plaque, mais je me méfie de ce
que fait le compilateur des caractères non-ascii, je ferais
plutôt des tests en tapant un caractere d'une façon standard :
uC3A0
(ça devrait être 'à', à moins que je me sois gouré dans mes
codes..)
bon, je dis pas que ça va forcément changer qque chose, mais
au moins ça évite d'ajouter d'éventuels problèmes
d'interpretation du caractère par le compilateur.
D'ailleurs, si on veut mettre des caractères non ascii dans un
source, le seul moyen portable est de tous les traduire en
"universal character name", non ?
le Wednesday 20 April 2005 19:02, écrivit :file << L"à";
je suis peut-être à coté de la plaque, mais je me méfie de ce
que fait le compilateur des caractères non-ascii, je ferais
plutôt des tests en tapant un caractere d'une façon standard :
uC3A0
(ça devrait être 'à', à moins que je me sois gouré dans mes
codes..)
bon, je dis pas que ça va forcément changer qque chose, mais
au moins ça évite d'ajouter d'éventuels problèmes
d'interpretation du caractère par le compilateur.
D'ailleurs, si on veut mettre des caractères non ascii dans un
source, le seul moyen portable est de tous les traduire en
"universal character name", non ?
D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
Samuel Krempp writes:D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
C'est portables aux implémentations conformes, mais est-ce
que les compilateurs courant sont conformes sur ce point?
Ma question est sincère, je ne me suis jamais amusé à
tester.
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:
D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
C'est portables aux implémentations conformes, mais est-ce
que les compilateurs courant sont conformes sur ce point?
Ma question est sincère, je ne me suis jamais amusé à
tester.
Samuel Krempp writes:D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
C'est portables aux implémentations conformes, mais est-ce
que les compilateurs courant sont conformes sur ce point?
Ma question est sincère, je ne me suis jamais amusé à
tester.
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Tu as dû te gourer : uC3A0 est un caractère Hangul. Le code
correct est u00E0. (En général, les codes ISO 8859-1 sont
identique en Unicode, ce qui veut dire que les deux premiers
chiffres d'un u seront toujours 00.)
le code 0x30000060 -- pas Unicode du tout), mais g++ le rejette
avec le message d'erreur « converting to execution character
set: Invalid argument » (ce qui est sont droit, même si on
pourrait en discuter au niveau de la qualité de
l'implémentation).
Dans la pratique, la seule solution réelement fiable, c'est de
lire les messages d'un fichier externe:-(.
Pour les char, 'à' donne les bons résultats avec les deux
compilateurs ; CC n'accepte pas 'u00E0', et curieusement (parce
qu'il supporte manifestement les "universal character name"),
g++ donne un avertisement "warning: multi-character character
constant" et génère 0xA0 !
Ce qui est intéressant, c'est que 'à' marche à peu près partout.
Pour des raisons sans doute historique, quand il s'agit des
"..." ou des '...', les compilateurs que je connais passent le
contenu du fichier de façon transparamment, sans trop poser de
questions. Si lors des sorties sur l'écran, le font utilise le
même encodage que lorsque j'ai édité le fichier source, tout se
passe bien. Sinon...
Samuel Krempp writes:D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
C'est portables aux implémentations conformes,
mais est-ce que les compilateurs courant sont conformes sur ce
point?
Ma question est sincère, je ne me suis jamais amusé à tester.
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:
D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
C'est portables aux implémentations conformes,
mais est-ce que les compilateurs courant sont conformes sur ce
point?
Ma question est sincère, je ne me suis jamais amusé à tester.
Samuel Krempp writes:D'ailleurs, si on veut mettre des caractères non ascii
dans un source, le seul moyen portable est de tous les
traduire en "universal character name", non ?
C'est portables aux implémentations conformes,
mais est-ce que les compilateurs courant sont conformes sur ce
point?
Ma question est sincère, je ne me suis jamais amusé à tester.