Lecture d'un fichier mixant du char * et de l'unicode

Fabien LE LEZ

16/07/2007 à 14:34

On Mon, 16 Jul 2007 05:19:53 -0700, :

[NomDuChamp]
Valeur du Champ

ou nom du champ est en char 'std' (sur 8 bits quoi) et valeur du champ
est en unicode (pour supporter toutes les langues).

Per se, "en unicode" ne veut pas dire grand-chose.
Typiquement, un fichier texte (ou HTML, ou un e-mail) est encodé en
UTF-8. L'avantage, c'est que les caractères ASCII (de 32 à 127) ne
sont pas modifiés ; ainsi, le "NomDuChamp" sera probablement à la fois
en UTF-8 et en ASCII (ou ISO-Latin-1).

Typiquement toujours, en RAM, on stocke les caractères sous forme de
"wide chars" (i.e. chaque caractère occupe 16 bits). En C++, ça veut
dire remplacer char par wchar_t, string par wstring, etc.

Il suffit ensuite de t'assurer que la conversion se fait bien à chaque
lecture et à chaque écriture.

vdaanen

16/07/2007 à 15:59

On 16 juil, 14:34, Fabien LE LEZ wrote:

Il suffit ensuite de t'assurer que la conversion se fait bien à chaque
lecture et à chaque écriture.

Ok !

bon alors la question devient : que dois-je faire pour convertir une
chaine wchar_t en sa representation japonaise (ce n'est qu'un exemple,
j'ai kkun qui a pu me faire un petit fichier avec du japonais
dedans :) ) et l'afficher.

Merci de ton aide
V

James Kanze

17/07/2007 à 09:44

On Jul 16, 2:19 pm, wrote:

j'ai besoin de permettre a un programme (sous windows XP) de parler
n'importe quelle langue.

Actuellement, nous pouvons gerer facilement les langues
'classiques' (francais, anglais, allemand, espagnol, etc..) enfin
toute celle dont les caracteres peuvent se coder sur 8 bits.

Or voila qu'on nous demande de supporter ... les chinois, l'hébreu,
l'indien etc..

voila ce que nous aimerions faire :
[NomDuChamp]
Valeur du Champ

ou nom du champ est en char 'std' (sur 8 bits quoi)

Avec seulement des caractères de base (ceux dans le « basic
execution character set ») ?

et valeur du champ
est en unicode (pour supporter toutes les langues).

Quel format de représentation ? (UTF-8, UTF-16 ou UTF-32, BE ou
LE pour des deux derniers ?)

L'objectif etant d'afficher ces messages sur une interface
utilisateur.

La première question, c'est qui créer ce fichier.

Logiquement, s'il ne s'agit que des messages à afficher, et les
noms de champs ne comportent que des caractères de base, le plus
simple serait d'utiliser le UTF-8 partout. Seulement :

-- Pour l'affichage, il faut bien utiliser l'encodage et le
format que veut la bibliothèque d'affichage. Ce qui implique
éventuellement un transcodage. (Windows utilise UTF-16LE,
je crois. La plupart d'Unix peuvent s'en tirer avec UTF-8,
*si* les bons fonts sont installés. Ce qui n'est pas
forcement le cas par défaut.)

-- Pour générer le fichier (si ce n'est pas ton programme qui
l'écrit), il faut bien que l'outil utilisé peut écrire aussi
du UTF-8. C'est le cas des éditeurs de programmation les
plus répandus sous Unix (emacs, vim), encore que là aussi,
il faut vérifier la configuration et les options avec
lesquelles ils ont été compilés. Sous Windows, en revanche,
je crois que c'est plutôt l'exception. Pour son Unicode,
Windows utilise assez systèmatiquement UTF-16LE.

L'alternatif, c'est de travailler avec des wchar_t en interne,
et avec le bon locale (facette codecvt) pour lire le fichier. Ce
que tu ne peux pas faire, au moins avec les iostream classiques,
c'est de changer l'encodage en cour de route. (La seule
exception, c'est si tu commences avec un encodage sans état,
c-à-d « single byte ». Ce qui permet, par exemple, de lire des
fichiers HTML en locale "C" jusqu'à la rencontre de la
spécification d'encodage dans l'en-tête, puis de continuer avec
l'encodage spécifié. Mais une fois passé en UTF-8, pas question
de revenir.) En plus, si le fichier doit être créer avec un
autre outil (éditeur, etc.), je ne connais aucun outil qui
permettrait de générer un fichier dont l'encodage varie d'une
ligne à l'autre.

Si tu travaille sous Windows, à mon avis, la question est tout
reglée. Windows utilise UTF-16LE partout. Tu passes en wchar_t
(il y a même des macros pour ça, je crois), et c'est tout. Des
constantes de chaîne larges sont en UTF-16LE ; alors, des
comparaisons du genre :
if ( line == L"[champ1]" )
ne doivent poser aucun problème. La seule chose, d'est de
trouver le bon locale pour imbuer le flux de lecture.

Si tu travailles sous Unix, ou si tu veux être portable aux
deux, le problème est un peu plus compliqué, parce qu'il n'y a
pas vraiment de standard sous Unix (même si on tend de plus en
plus vers UTF-8). En principe, tu dois pouvoir créer le fichier
en UTF-8, puis au moyen du bon locale, le lire avec UTF-32 (la
plupart) ou UTF-16 (AIX), et de travailler interne en wchar_t,
exactement comme sous Windows. Il risque d'avoir de la variation
dans l'encodage utilisé pour les constantes de chaîne larges,
mais dans la pratique, l'encodage des caractères de base serait
le même que dans l'Unicode utilisé. (Et dans la pratique,
certains compilateurs Unix ne supportent pas encore les UCN, et
ne permettent pas de caractères en dehors des caractères de base
dans les chaînes larges.)

Reste à trouver le locale qui te convient. A priori, je
m'attendrais à ce qu'il soit fourni sous Windows, mais je ne
crois pas qu'il soit le défaut (et je ne sais pas comment on
nomme les locales sous Windows). Sous Unix, il faudrait
probablement que tu t'adresses à un fournisseur externe.
(Dinkumware a beaucoup de locales d'extension, mais je ne sais
pas s'il marche avec des bibliothèques autres que Dinkumware.)

--
James Kanze (GABI Software) email:
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

On Jul 16, 2:19 pm, vdaa...@yahoo.fr wrote:

j'ai besoin de permettre a un programme (sous windows XP) de parler
n'importe quelle langue.

Actuellement, nous pouvons gerer facilement les langues
'classiques' (francais, anglais, allemand, espagnol, etc..) enfin
toute celle dont les caracteres peuvent se coder sur 8 bits.

Or voila qu'on nous demande de supporter ... les chinois, l'hébreu,
l'indien etc..

voila ce que nous aimerions faire :
[NomDuChamp]
Valeur du Champ

ou nom du champ est en char 'std' (sur 8 bits quoi)

Avec seulement des caractères de base (ceux dans le « basic
execution character set ») ?

et valeur du champ
est en unicode (pour supporter toutes les langues).

Quel format de représentation ? (UTF-8, UTF-16 ou UTF-32, BE ou
LE pour des deux derniers ?)

L'objectif etant d'afficher ces messages sur une interface
utilisateur.

La première question, c'est qui créer ce fichier.

Logiquement, s'il ne s'agit que des messages à afficher, et les
noms de champs ne comportent que des caractères de base, le plus
simple serait d'utiliser le UTF-8 partout. Seulement :

-- Pour l'affichage, il faut bien utiliser l'encodage et le
format que veut la bibliothèque d'affichage. Ce qui implique
éventuellement un transcodage. (Windows utilise UTF-16LE,
je crois. La plupart d'Unix peuvent s'en tirer avec UTF-8,
*si* les bons fonts sont installés. Ce qui n'est pas
forcement le cas par défaut.)

-- Pour générer le fichier (si ce n'est pas ton programme qui
l'écrit), il faut bien que l'outil utilisé peut écrire aussi
du UTF-8. C'est le cas des éditeurs de programmation les
plus répandus sous Unix (emacs, vim), encore que là aussi,
il faut vérifier la configuration et les options avec
lesquelles ils ont été compilés. Sous Windows, en revanche,
je crois que c'est plutôt l'exception. Pour son Unicode,
Windows utilise assez systèmatiquement UTF-16LE.

L'alternatif, c'est de travailler avec des wchar_t en interne,
et avec le bon locale (facette codecvt) pour lire le fichier. Ce
que tu ne peux pas faire, au moins avec les iostream classiques,
c'est de changer l'encodage en cour de route. (La seule
exception, c'est si tu commences avec un encodage sans état,
c-à-d « single byte ». Ce qui permet, par exemple, de lire des
fichiers HTML en locale "C" jusqu'à la rencontre de la
spécification d'encodage dans l'en-tête, puis de continuer avec
l'encodage spécifié. Mais une fois passé en UTF-8, pas question
de revenir.) En plus, si le fichier doit être créer avec un
autre outil (éditeur, etc.), je ne connais aucun outil qui
permettrait de générer un fichier dont l'encodage varie d'une
ligne à l'autre.

Si tu travaille sous Windows, à mon avis, la question est tout
reglée. Windows utilise UTF-16LE partout. Tu passes en wchar_t
(il y a même des macros pour ça, je crois), et c'est tout. Des
constantes de chaîne larges sont en UTF-16LE ; alors, des
comparaisons du genre :
if ( line == L"[champ1]" )
ne doivent poser aucun problème. La seule chose, d'est de
trouver le bon locale pour imbuer le flux de lecture.

Si tu travailles sous Unix, ou si tu veux être portable aux
deux, le problème est un peu plus compliqué, parce qu'il n'y a
pas vraiment de standard sous Unix (même si on tend de plus en
plus vers UTF-8). En principe, tu dois pouvoir créer le fichier
en UTF-8, puis au moyen du bon locale, le lire avec UTF-32 (la
plupart) ou UTF-16 (AIX), et de travailler interne en wchar_t,
exactement comme sous Windows. Il risque d'avoir de la variation
dans l'encodage utilisé pour les constantes de chaîne larges,
mais dans la pratique, l'encodage des caractères de base serait
le même que dans l'Unicode utilisé. (Et dans la pratique,
certains compilateurs Unix ne supportent pas encore les UCN, et
ne permettent pas de caractères en dehors des caractères de base
dans les chaînes larges.)

Reste à trouver le locale qui te convient. A priori, je
m'attendrais à ce qu'il soit fourni sous Windows, mais je ne
crois pas qu'il soit le défaut (et je ne sais pas comment on
nomme les locales sous Windows). Sous Unix, il faudrait
probablement que tu t'adresses à un fournisseur externe.
(Dinkumware a beaucoup de locales d'extension, mais je ne sais
pas s'il marche avec des bibliothèques autres que Dinkumware.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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

Vous avez filtré cet utilisateur ! Consultez son message

On Jul 16, 2:19 pm, wrote:

j'ai besoin de permettre a un programme (sous windows XP) de parler
n'importe quelle langue.

Actuellement, nous pouvons gerer facilement les langues
'classiques' (francais, anglais, allemand, espagnol, etc..) enfin
toute celle dont les caracteres peuvent se coder sur 8 bits.

Or voila qu'on nous demande de supporter ... les chinois, l'hébreu,
l'indien etc..

voila ce que nous aimerions faire :
[NomDuChamp]
Valeur du Champ

ou nom du champ est en char 'std' (sur 8 bits quoi)

Avec seulement des caractères de base (ceux dans le « basic
execution character set ») ?

et valeur du champ
est en unicode (pour supporter toutes les langues).

Quel format de représentation ? (UTF-8, UTF-16 ou UTF-32, BE ou
LE pour des deux derniers ?)

L'objectif etant d'afficher ces messages sur une interface
utilisateur.

La première question, c'est qui créer ce fichier.

Logiquement, s'il ne s'agit que des messages à afficher, et les
noms de champs ne comportent que des caractères de base, le plus
simple serait d'utiliser le UTF-8 partout. Seulement :

-- Pour l'affichage, il faut bien utiliser l'encodage et le
format que veut la bibliothèque d'affichage. Ce qui implique
éventuellement un transcodage. (Windows utilise UTF-16LE,
je crois. La plupart d'Unix peuvent s'en tirer avec UTF-8,
*si* les bons fonts sont installés. Ce qui n'est pas
forcement le cas par défaut.)

-- Pour générer le fichier (si ce n'est pas ton programme qui
l'écrit), il faut bien que l'outil utilisé peut écrire aussi
du UTF-8. C'est le cas des éditeurs de programmation les
plus répandus sous Unix (emacs, vim), encore que là aussi,
il faut vérifier la configuration et les options avec
lesquelles ils ont été compilés. Sous Windows, en revanche,
je crois que c'est plutôt l'exception. Pour son Unicode,
Windows utilise assez systèmatiquement UTF-16LE.

L'alternatif, c'est de travailler avec des wchar_t en interne,
et avec le bon locale (facette codecvt) pour lire le fichier. Ce
que tu ne peux pas faire, au moins avec les iostream classiques,
c'est de changer l'encodage en cour de route. (La seule
exception, c'est si tu commences avec un encodage sans état,
c-à-d « single byte ». Ce qui permet, par exemple, de lire des
fichiers HTML en locale "C" jusqu'à la rencontre de la
spécification d'encodage dans l'en-tête, puis de continuer avec
l'encodage spécifié. Mais une fois passé en UTF-8, pas question
de revenir.) En plus, si le fichier doit être créer avec un
autre outil (éditeur, etc.), je ne connais aucun outil qui
permettrait de générer un fichier dont l'encodage varie d'une
ligne à l'autre.

Si tu travaille sous Windows, à mon avis, la question est tout
reglée. Windows utilise UTF-16LE partout. Tu passes en wchar_t
(il y a même des macros pour ça, je crois), et c'est tout. Des
constantes de chaîne larges sont en UTF-16LE ; alors, des
comparaisons du genre :
if ( line == L"[champ1]" )
ne doivent poser aucun problème. La seule chose, d'est de
trouver le bon locale pour imbuer le flux de lecture.

Si tu travailles sous Unix, ou si tu veux être portable aux
deux, le problème est un peu plus compliqué, parce qu'il n'y a
pas vraiment de standard sous Unix (même si on tend de plus en
plus vers UTF-8). En principe, tu dois pouvoir créer le fichier
en UTF-8, puis au moyen du bon locale, le lire avec UTF-32 (la
plupart) ou UTF-16 (AIX), et de travailler interne en wchar_t,
exactement comme sous Windows. Il risque d'avoir de la variation
dans l'encodage utilisé pour les constantes de chaîne larges,
mais dans la pratique, l'encodage des caractères de base serait
le même que dans l'Unicode utilisé. (Et dans la pratique,
certains compilateurs Unix ne supportent pas encore les UCN, et
ne permettent pas de caractères en dehors des caractères de base
dans les chaînes larges.)

Reste à trouver le locale qui te convient. A priori, je
m'attendrais à ce qu'il soit fourni sous Windows, mais je ne
crois pas qu'il soit le défaut (et je ne sais pas comment on
nomme les locales sous Windows). Sous Unix, il faudrait
probablement que tu t'adresses à un fournisseur externe.
(Dinkumware a beaucoup de locales d'extension, mais je ne sais
pas s'il marche avec des bibliothèques autres que Dinkumware.)

--
James Kanze (GABI Software) email:
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

James Kanze

17/07/2007 à 10:33

On Jul 16, 2:34 pm, Fabien LE LEZ wrote:

On Mon, 16 Jul 2007 05:19:53 -0700, :

[NomDuChamp]
Valeur du Champ

ou nom du champ est en char 'std' (sur 8 bits quoi) et valeur du champ
est en unicode (pour supporter toutes les langues).

Per se, "en unicode" ne veut pas dire grand-chose.
Typiquement, un fichier texte (ou HTML, ou un e-mail) est encodé en
UTF-8.

D'après ce que j'ai entendu dire, ce n'est pas si typique sous
Windows, ou un fichier « Unicode » serait normalement
UTF-16LE. Et sous Solaris, l'Unicode n'existe pour ainsi dire
pas ; on ne peut donc pas dire ce qui est typique.

Ce qu'on peut dire, c'est que 1) UTF-8 est la seule
représentation d'Unicode sur des octets, et donc le choix
logique pour un médium orienté octet, et 2) UTF-8 est la seule
représentation supportée sur l'Internet (en dehors des
protocoles de transfert transparent binaire, comme FTP en mode
binaire). En revanche, s'il crée un fichier « Unicode » sous
Windows, il y a des chances qu'il soit en UTF-16LE (encore que
je vois dans la documentation de Notepad qu'il dit « You can
save your Notepad files as Unicode, ANSI, UTF-8, or big-endian
Unicode. » (J'imagine qu'ici « Unicode » veut dire UTF-16LE,
et « big-endian Unicode » UTF-16BE.)

Puisque les éditeurs Unix ont aussi en général une option UTF-8
aussi, voilà une solution portable pour la génération du
fichier.

Pour son traitement interne, UTF-8 convient parfaitement aussi.
Il n'y a pas de raison à passer à wchar_t pour ça.

Reste le problème de l'affichage. Sous Windows, je *crois* (je
suis loin d'être sûr) qu'il faut qu'il utiliser wchar_t avec des
UTF-16. Sous Unix (ou plus précisement, sous X---Mac est encore
une autre question, dont je ne connais rien), au moins d'après
mon expérience (parce qu'il peut bien qu'il y a d'autres
solutions), c'est de travailler en octets, dont l'interprétation
dépend de la police selectionné. (Je ne sais pas si X a aussi
une interface wchar_t. S'il l'a, l'encodage dépendrait aussi
sans doute de la police sélectionnée.)

L'avantage, c'est que les caractères ASCII (de 32 à 127) ne
sont pas modifiés ; ainsi, le "NomDuChamp" sera probablement à la fois
en UTF-8 et en ASCII (ou ISO-Latin-1).

Dans le fichier, oui. Une des raisons pourquoi UTF-8 s'est
imposé sur le reseau, c'est que tous les programmes qui
comparent des chaînes avec des constantes en ASCII continuent à
marcher.

Typiquement toujours, en RAM, on stocke les caractères sous forme de
"wide chars" (i.e. chaque caractère occupe 16 bits).

AMHA, ça dépend beaucoup de ce qu'on va en faire. Ça
m'étonnerait qu'un serveur de Web stocke quoique ce soit en
wchar_t, par exemple. Pour ce qu'il fait lui-même, travailler
directement en UTF-8 conviendrait parfaitement. Si, comme j'ai
l'impression, il s'agit des messages à afficher, en revanche, il
faut qu'il prenne en compte ce auquel s'attend le système de
fenêtrage (Windows, X, etc.).

Et en passant, wchar_t fait 32 bits sur la majorité des
systèmes. Windows et AIX sont les grandes exceptions.

En C++, ça veut dire remplacer char par wchar_t, string par
wstring, etc.

Il suffit ensuite de t'assurer que la conversion se fait bien
à chaque lecture et à chaque écriture.

C'est la rôle des facettes.

Ce qui est important, par rapport à sa première démande, c'est
qu'il ne peut pas changer l'encodage en cour de route. Il ne
peut pas utiliser l'ASCII pour les étiquettes, par exemple, et
UTF-16LE pour les contenus des champs. Mais ce n'est pas un
problème ; s'il utilise UTF-8 en interne, les caractères de
base auront tous le même encodage que dans l'ASCII, et s'il
utilise wchar_t, les valeurs numériques en seront les mêmes, de
même que les encodages dans les L"..." (pour les caractères de
base -- pour la reste, je le doute).

--
James Kanze (GABI Software) email:
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

On Jul 16, 2:34 pm, Fabien LE LEZ <grams...@gramster.com> wrote:

On Mon, 16 Jul 2007 05:19:53 -0700, vdaa...@yahoo.fr:

[NomDuChamp]
Valeur du Champ

ou nom du champ est en char 'std' (sur 8 bits quoi) et valeur du champ
est en unicode (pour supporter toutes les langues).

Per se, "en unicode" ne veut pas dire grand-chose.
Typiquement, un fichier texte (ou HTML, ou un e-mail) est encodé en
UTF-8.

D'après ce que j'ai entendu dire, ce n'est pas si typique sous
Windows, ou un fichier « Unicode » serait normalement
UTF-16LE. Et sous Solaris, l'Unicode n'existe pour ainsi dire
pas ; on ne peut donc pas dire ce qui est typique.

Ce qu'on peut dire, c'est que 1) UTF-8 est la seule
représentation d'Unicode sur des octets, et donc le choix
logique pour un médium orienté octet, et 2) UTF-8 est la seule
représentation supportée sur l'Internet (en dehors des
protocoles de transfert transparent binaire, comme FTP en mode
binaire). En revanche, s'il crée un fichier « Unicode » sous
Windows, il y a des chances qu'il soit en UTF-16LE (encore que
je vois dans la documentation de Notepad qu'il dit « You can
save your Notepad files as Unicode, ANSI, UTF-8, or big-endian
Unicode. » (J'imagine qu'ici « Unicode » veut dire UTF-16LE,
et « big-endian Unicode » UTF-16BE.)

Puisque les éditeurs Unix ont aussi en général une option UTF-8
aussi, voilà une solution portable pour la génération du
fichier.

Pour son traitement interne, UTF-8 convient parfaitement aussi.
Il n'y a pas de raison à passer à wchar_t pour ça.

Reste le problème de l'affichage. Sous Windows, je *crois* (je
suis loin d'être sûr) qu'il faut qu'il utiliser wchar_t avec des
UTF-16. Sous Unix (ou plus précisement, sous X---Mac est encore
une autre question, dont je ne connais rien), au moins d'après
mon expérience (parce qu'il peut bien qu'il y a d'autres
solutions), c'est de travailler en octets, dont l'interprétation
dépend de la police selectionné. (Je ne sais pas si X a aussi
une interface wchar_t. S'il l'a, l'encodage dépendrait aussi
sans doute de la police sélectionnée.)

L'avantage, c'est que les caractères ASCII (de 32 à 127) ne
sont pas modifiés ; ainsi, le "NomDuChamp" sera probablement à la fois
en UTF-8 et en ASCII (ou ISO-Latin-1).

Dans le fichier, oui. Une des raisons pourquoi UTF-8 s'est
imposé sur le reseau, c'est que tous les programmes qui
comparent des chaînes avec des constantes en ASCII continuent à
marcher.

Typiquement toujours, en RAM, on stocke les caractères sous forme de
"wide chars" (i.e. chaque caractère occupe 16 bits).

AMHA, ça dépend beaucoup de ce qu'on va en faire. Ça
m'étonnerait qu'un serveur de Web stocke quoique ce soit en
wchar_t, par exemple. Pour ce qu'il fait lui-même, travailler
directement en UTF-8 conviendrait parfaitement. Si, comme j'ai
l'impression, il s'agit des messages à afficher, en revanche, il
faut qu'il prenne en compte ce auquel s'attend le système de
fenêtrage (Windows, X, etc.).

Et en passant, wchar_t fait 32 bits sur la majorité des
systèmes. Windows et AIX sont les grandes exceptions.

En C++, ça veut dire remplacer char par wchar_t, string par
wstring, etc.

Il suffit ensuite de t'assurer que la conversion se fait bien
à chaque lecture et à chaque écriture.

C'est la rôle des facettes.

Ce qui est important, par rapport à sa première démande, c'est
qu'il ne peut pas changer l'encodage en cour de route. Il ne
peut pas utiliser l'ASCII pour les étiquettes, par exemple, et
UTF-16LE pour les contenus des champs. Mais ce n'est pas un
problème ; s'il utilise UTF-8 en interne, les caractères de
base auront tous le même encodage que dans l'ASCII, et s'il
utilise wchar_t, les valeurs numériques en seront les mêmes, de
même que les encodages dans les L"..." (pour les caractères de
base -- pour la reste, je le doute).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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

Vous avez filtré cet utilisateur ! Consultez son message

On Jul 16, 2:34 pm, Fabien LE LEZ wrote:

On Mon, 16 Jul 2007 05:19:53 -0700, :

[NomDuChamp]
Valeur du Champ

ou nom du champ est en char 'std' (sur 8 bits quoi) et valeur du champ
est en unicode (pour supporter toutes les langues).

Per se, "en unicode" ne veut pas dire grand-chose.
Typiquement, un fichier texte (ou HTML, ou un e-mail) est encodé en
UTF-8.

D'après ce que j'ai entendu dire, ce n'est pas si typique sous
Windows, ou un fichier « Unicode » serait normalement
UTF-16LE. Et sous Solaris, l'Unicode n'existe pour ainsi dire
pas ; on ne peut donc pas dire ce qui est typique.

Ce qu'on peut dire, c'est que 1) UTF-8 est la seule
représentation d'Unicode sur des octets, et donc le choix
logique pour un médium orienté octet, et 2) UTF-8 est la seule
représentation supportée sur l'Internet (en dehors des
protocoles de transfert transparent binaire, comme FTP en mode
binaire). En revanche, s'il crée un fichier « Unicode » sous
Windows, il y a des chances qu'il soit en UTF-16LE (encore que
je vois dans la documentation de Notepad qu'il dit « You can
save your Notepad files as Unicode, ANSI, UTF-8, or big-endian
Unicode. » (J'imagine qu'ici « Unicode » veut dire UTF-16LE,
et « big-endian Unicode » UTF-16BE.)

Puisque les éditeurs Unix ont aussi en général une option UTF-8
aussi, voilà une solution portable pour la génération du
fichier.

Pour son traitement interne, UTF-8 convient parfaitement aussi.
Il n'y a pas de raison à passer à wchar_t pour ça.

Reste le problème de l'affichage. Sous Windows, je *crois* (je
suis loin d'être sûr) qu'il faut qu'il utiliser wchar_t avec des
UTF-16. Sous Unix (ou plus précisement, sous X---Mac est encore
une autre question, dont je ne connais rien), au moins d'après
mon expérience (parce qu'il peut bien qu'il y a d'autres
solutions), c'est de travailler en octets, dont l'interprétation
dépend de la police selectionné. (Je ne sais pas si X a aussi
une interface wchar_t. S'il l'a, l'encodage dépendrait aussi
sans doute de la police sélectionnée.)

L'avantage, c'est que les caractères ASCII (de 32 à 127) ne
sont pas modifiés ; ainsi, le "NomDuChamp" sera probablement à la fois
en UTF-8 et en ASCII (ou ISO-Latin-1).

Dans le fichier, oui. Une des raisons pourquoi UTF-8 s'est
imposé sur le reseau, c'est que tous les programmes qui
comparent des chaînes avec des constantes en ASCII continuent à
marcher.

Typiquement toujours, en RAM, on stocke les caractères sous forme de
"wide chars" (i.e. chaque caractère occupe 16 bits).

AMHA, ça dépend beaucoup de ce qu'on va en faire. Ça
m'étonnerait qu'un serveur de Web stocke quoique ce soit en
wchar_t, par exemple. Pour ce qu'il fait lui-même, travailler
directement en UTF-8 conviendrait parfaitement. Si, comme j'ai
l'impression, il s'agit des messages à afficher, en revanche, il
faut qu'il prenne en compte ce auquel s'attend le système de
fenêtrage (Windows, X, etc.).

Et en passant, wchar_t fait 32 bits sur la majorité des
systèmes. Windows et AIX sont les grandes exceptions.

En C++, ça veut dire remplacer char par wchar_t, string par
wstring, etc.

Il suffit ensuite de t'assurer que la conversion se fait bien
à chaque lecture et à chaque écriture.

C'est la rôle des facettes.

Ce qui est important, par rapport à sa première démande, c'est
qu'il ne peut pas changer l'encodage en cour de route. Il ne
peut pas utiliser l'ASCII pour les étiquettes, par exemple, et
UTF-16LE pour les contenus des champs. Mais ce n'est pas un
problème ; s'il utilise UTF-8 en interne, les caractères de
base auront tous le même encodage que dans l'ASCII, et s'il
utilise wchar_t, les valeurs numériques en seront les mêmes, de
même que les encodages dans les L"..." (pour les caractères de
base -- pour la reste, je le doute).

--
James Kanze (GABI Software) email:
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

vdaanen

17/07/2007 à 11:28

Bonjour,

merci de ces reponses précises.
Je vais analyser tout ca et revenir vers le forum je pense car en
lisant en diagonales, ca ne me parait pas simple !

V

Olivier Miakinen

17/07/2007 à 12:01

Il suffit ensuite de t'assurer que la conversion se fait bien à chaque
lecture et à chaque écriture.

Ok !

bon alors la question devient : que dois-je faire pour convertir une
chaine wchar_t en sa representation japonaise

La première question est plutôt *quelle* représentation japonaise ?
Et accessoirement, quelle représentation « wchar_t » ?

D'après James Kanze, si c'est sur Windows il y a toutes les chances que
les wchar_t contiennent de l'UTF-16LE. Pour ce qui est du fichier qu'on
t'a passé avec du japonais dedans, là encore il faudrait savoir en quoi
il est.

Une façon de le savoir, c'est de visualiser le fichier avec Mozilla ou
Firefox, et de changer le jeu de caractères (View / Character encoding)
jusqu'à ce que l'image devienne nette, c.-à-d. que tu voies vraiment des
caractères japonais plutôt que des machins bizarroïdes ou des points
d'interrogation. Je te conseille d'essayer en particulier Shift_JIS,
qui est ce que je vois le plus souvent, mais il y a aussi EUC-JP,
ISO-2022-JP, et bien sûr UTF-16(LE ou BE) et UTF-8.

Fabien LE LEZ

17/07/2007 à 13:50

On Tue, 17 Jul 2007 12:01:06 +0200, Olivier Miakinen
<om+:

jusqu'à ce que l'image devienne nette, c.-à-d. que tu voies vraiment des
caractères japonais plutôt que des machins bizarroïdes ou des points
d'interrogation.

À condition d'avoir les polices adéquates installées sur le système.

Fabien LE LEZ

17/07/2007 à 13:54

On Tue, 17 Jul 2007 02:28:21 -0700, :

ca ne me parait pas simple !

Je confirme.

<HS>
Je développe une application web en ce moment, et pour contourner les
problèmes style "UTF-8 vs ISO-Latin1", j'ai décidé d'employer une
méthode bourrin : je convertis tout en entités HTML ("&eactute;" et
compagnie), et je laisse le navigateur se démerder avec ça.

Olivier Miakinen

17/07/2007 à 14:36

jusqu'à ce que l'image devienne nette, c.-à-d. que tu voies vraiment des
caractères japonais plutôt que des machins bizarroïdes ou des points
d'interrogation.

À condition d'avoir les polices adéquates installées sur le système.

Ah oui, exact. Je n'y pensais pas, car j'ai moi-même installé tout ce
que j'ai pu comme polices et extensions linguistiques quand j'ai dû
intégrer des pages dans diverses langues, et je ne me rappelle même
pas comment j'avais fait.

<HS>
Je développe une application web en ce moment, et pour contourner les
problèmes style "UTF-8 vs ISO-Latin1", j'ai décidé d'employer une
méthode bourrin : je convertis tout en entités HTML ("&eactute;" et
compagnie), et je laisse le navigateur se démerder avec ça.

C'est encore envisageable pour les langues occidentales, dans lesquelles
peu de caractères sortent des 7 bits d'US-ASCII, mais pas du tout pour
du japonais où tout ressemblerait à « 日本語版 »

Fabien LE LEZ

17/07/2007 à 14:45

On Tue, 17 Jul 2007 14:36:11 +0200, Olivier Miakinen
<om+:

C'est encore envisageable pour les langues occidentales, dans lesquelles
peu de caractères sortent des 7 bits d'US-ASCII, mais pas du tout pour
du japonais où tout ressemblerait à « 日本語版 »

Pour moi, c'est largement aussi lisible que des kanjis.

Par ailleurs, si le Japonais qui tape, utilise un éditeur capable de
pondre ce genre de code, il peut facilement vérifier que le code est
bon avec un navigateur. Ensuite, une fois que j'ai ce code imbuvable,
comme c'est du ASCII pur (32-127), je peux le faire passer par tous
les filtres que je veux (SMTP, MySQL, etc.) sans problèmes.

Lecture d'un fichier mixant du char * et de l'unicode

10 réponses

Veuillez sélectionner un problème