Discussion :

[Nico_stras]

Bonjour,
Je me pose des question au sujet de l'encodage des caractères.

en C, en déclarant un caractère de type "char", 8 bits sont alloués.
Si le caractère est compris entre 0 et 127, il se trouve dans la table ASCII, donc aucun problème.

Par contre, les autres caractères (é, ç, ..., caractères exotiques, ...) possèdent un numéro unicode, et sont éventuellement présent dans une (ou plusieurs) tables de la plage 128-255.

Quel est l'encodage utilisé par le compilateur ?
Quel doit être l'encodage du code source dans lequel sont définis des chaines de caractères ?
Quel est l'encodage utilisé lorsque l'on ouvre un fichier texte ?

Est-il possible (judicieux) d'utiliser dans toute le cycle de développement (codage, compilation, exécution, ...) de l'UTF-8 ?

Merci pour vos remarques

Nicolas
Strasbourg

[Jean-Marc.Bourguet]

Bonjour, Je me pose des question au sujet de
l'encodage des caractères.

Ne t'en fais pas, ceux qui ne s'en posent pas n'ont vraisemblablement pas
compris le probleme.

en C, en déclarant un caractère de type "char", 8 bits sont
alloués.

Au minimum.

Si le caractère est compris entre 0 et 127, il se trouve dans la
table ASCII, donc aucun problème.

Pas necessairement. L'utilisation d'ASCII n'est en rien obligatoire. Il y
a des implementations qui utilisent EBCDIC.

Par contre, les autres caractères (é, ç, ..., caractères exotiques,
...) possèdent un numéro unicode,

Oui. Mais il y a d'autres charsets qu'Unicode.

et sont éventuellement présent dans une (ou plusieurs) tables de la
plage 128-255.

Unicode s'etend largement au dela de cette plage.

Quel est l'encodage utilisé par le compilateur ?

Ca depend (du compilo, de l'OS, de la configuration, en particulier de la
locale utilisee par le compilateur -- gcc par exemple est capable d'en
gerer pas mal)

Quel doit être l'encodage du code source dans lequel sont définis
des chaines de caractères ?

Ca depend de la locale utilisee quand on execute le programme.

Quel est l'encodage utilisé lorsque l'on ouvre un fichier
texte?

Ca depend de l'editeur qui peut faire dependre ca de pas mal de chose (le
mien par exemple detecte un fichier LaTeX et utilise l'encodage indique par
le contenu LaTeX).

Est-il possible (judicieux) d'utiliser dans toute le cycle de
développement (codage, compilation, exécution, ...) de l'UTF-8 ?

Mon point de vue actuel est qu'il ne faut plus utiliser des chars mais
uniquement des wchar_t en interne sauf cas particulier (genre systeme ou
toutes les locales n'utilisent pas le meme encodage pour les wchar_t, ca
existe) ou la, il faut reflechir un peu plus.

Quelques documents, tous incomplets, j'espere completer le premier pour
faire en sorte qu'il soit complet. Les deux autres devraient alors etre
soit fusionne dedans, soit y faire reference.

http://www.bourguet.org/v2/cs/charset/

http://www.bourguet.org/v2/clang/libc90/caracteres.html

http://www.bourguet.org/v2/clang/caracteres/

[Nico_stras]

Mon point de vue actuel est qu'il ne faut plus utiliser des chars mais uniquement des wchar_t en interne sauf cas particulier (genre systeme ou toutes les locales n'utilisent pas le meme encodage pour les wchar_t, ca existe) ou la, il faut reflechir un peu plus.

Mais à quoi correspond ce "wchar_t" ?

Quand le tape un 'é' dans mon code source, comment sera-t-il interpréter par le compilateur ?
Comment connait-il le codage utilisé pour le code source ?

Quand on parle de "ANSI-C", cela veut-il dire que l'on utilise un encodage "ANSI" ?

Ca depend (du compilo, de l'OS, de la configuration, en particulier de la locale utilisee par le compilateur -- gcc par exemple est capable d'en gerer pas mal)

Qu'appelle-tu "locale" ?

[Jean-Marc.Bourguet]

Mais à quoi correspond ce "wchar_t" ?

C'est un type destine aux "caracteres larges", assez grand pour contenir le codet de n'importe quel caractere du charset de n'importe quelle locale.

Quand le tape un 'é' dans mon code source, comment sera-t-il interpréter par le compilateur ?

5 contextes:
- nom d'identificateur: comme un caractere unicode. Pas supporte par des compilateurs rependu: je deconseille.
- constante de caractere: defini par l'implementation; en pratique si dans le systeme d'encodage de l'implementation la representation de é ne prend qu'un byte, ce sera celui-la. Sinon, aucune idee.
- constante de chaine: l'encodage de é (eventuellement plusieurs bytes si le mecanisme d'encodage le demande)
- constante de caractere large (L'é'): la valeur de codet
- constante de chaine large: la valeur du codet.

Comment connait-il le codage utilisé pour le code source ?

Ca, c'est a voir dans la doc de ton editeur.

Quand on parle de "ANSI-C", cela veut-il dire que l'on utilise un encodage "ANSI" ?

ANSI, c'est l'organisme de normalisation americain (l'equivalent de l'AFNOR). Ils ont normalise le C en 89. Cette norme a ete reprise quasiment telle quelle par l'ISO en 90 et republiee comme norme nationale par l'ANSI, l'AFNOR, etc. Toujours dans le cadre de l'ISO et avec republication nationale, la norme C a ete amendee en 95, et une nouvelle version a ete publiee en 99. Parler d'ANSI C, c'est un provincialisme americain sauf si on parle specifiquement de la version de 89.

L'ANSI (qui portait a l'epoque un autre nom) a publie un charset: l'ASCII. Il n'y a pas de charset qui porte le nom ANSI -- bien que sous Windows on utilise ce terme. Mais le charset en question n'est pas clair dans mon esprit -- est-ce le charset local Win-1252, Win-1250, etc suivant la version -- ou est-ce obligatoirement Win-1252?

Voir les documents que j'ai indique.

[Nico_stras]

C'est un type destine aux "caracteres larges", assez grand pour contenir le codet de n'importe quel caractere du charset de n'importe quelle locale.

Comment définies-tu "la locale" ?

[Jean-Marc.Bourguet]

http://www.bourguet.org/v2/clang/libc90/locale_8h.html

[Nico_stras]

J'ai écrit un code source très simple avec NotePad++.
J'ai donc le choix pour l'enregistrer en ANSI ou UTF-8 ou ...

Le fichier UTF-8 contient un en-tête de 3 octets.
De plus il n'est pas compilable avec gcc. (ou faut-il une option ?)

A quoi correspond cette en-tête ? Est-ce dans la norme UTF-8 ?

Le "ANSI" correspond au "ISO 8859-1" ou "Latin-1" et ne comprend pas d'en-tête.

[Emmanuel Delahaye]

J'ai écrit un code source très simple avec NotePad++.
J'ai donc le choix pour l'enregistrer en ANSI ou UTF-8 ou ...

Le fichier UTF-8 contient un en-tête de 3 octets.
De plus il n'est pas compilable avec gcc. (ou faut-il une option ?)

Ne pas utiliser ce format pour enregistrer du code source C.

Le "ANSI" correspond au "ISO 8859-1" ou "Latin-1" et ne comprend pas d'en-tête.

C'est le format qu'il faut utiliser. Ceci dit, l'usage des caractères autres que :

http://delahaye.emmanuel.free.fr/spip.php?article6

dans un code source entraine un comportement dépendant de la plateforme.

Si on y tient, il vaut mieux utiliser l'Unicode, qui est porté par le type wchar_t et toutes les fonctions afférentes (<wchar.h>).

http://www.opengroup.org/onlinepubs/...h/wchar.h.html

Windows a défini un mécanisme couvrant les 2 modes (char et wchar_t) que l'on active selon la définition ou non d'une certaine macro, avec un jeu de macros... (_TCHAR, _T() etc.). C'est détaillé sur MSDN.

[Médinoc]

À noter que "ANSI" est souvent utilisé sous Windows pour désigner la page de code 1252 (qui n'est pas réellement ANSI) et ses sœurs.

Typiquement sous Windows, tout ce qui n'est ni wchar_t, ni dit "OEM" (pages de codes adaptées aux consoles, comme la 437 et la 850) est dit "ANSI".

[Nico_stras]

Ne pas utiliser [UTF_8] pour enregistrer du code source C.
C'est [ISO 8859-1 ou IBM PC 8] qu'il faut utiliser. Ceci dit, l'usage des caractères autres que : http://delahaye.emmanuel.free.fr/spip.php?article6 dans un code source entraine un comportement dépendant de la plateforme.

ok. Donc ne développant pas d'application DOS, Je m'en tiens à "ISO 8859-1" pour les commentaires.

Et pour un fichier shell (UNIX), c'est également la norme "ISO 8859-1"

Si on y tient, il vaut mieux utiliser l'Unicode, qui est porté par le type wchar_t et toutes les fonctions afférentes (<wchar.h>). http://www.opengroup.org/onlinepubs/...h/wchar.h.html

Qu'appelles-tu Unicode ? UTF-8 ? UTF-16 ? autre ?
comment définir dans le code source la chaine de caractères "bébé" avec le type wchar_t ?
Comment faire la lecture d'un fichier codé en UTF-8 ?
Un fichier UTF-8 contient obligatoirement un en-tête ?

Windows a défini un mécanisme couvrant les 2 modes (char et wchar_t) que l'on active selon la définition ou non d'une certaine macro, avec un jeu de macros... (_TCHAR, _T() etc.). C'est détaillé sur MSDN.

Celà existe aussi dans le monde UNIX ?

[Jean-Marc.Bourguet]

J'ai écrit un code source très simple avec NotePad++.
J'ai donc le choix pour l'enregistrer en ANSI ou UTF-8 ou ...

Le fichier UTF-8 contient un en-tête de 3 octets.
De plus il n'est pas compilable avec gcc. (ou faut-il une option ?)

Peut-etre un probleme de port sous Windows (vu que cet entete est courant sous Windows, son traitement devrait etre prevu). Peut-etre simplement un probleme de configuration, ces options (si elles sont deja presentes dans la version que tu utilises) aideront alors peut-etre (voir aussi la doc de gcc la dessus)

-fexec-charset=charset
-fwide-exec-charset=charset
-finput-charset=charset

A quoi correspond cette en-tête ?

BOM. Une sorte de signature d'abord utilisee pour indiquer le boutisme (chose sans objet pour UTF-8) et detournee pour indiquer le fait que c'est de l'Unicode encode en UTF-8.

Est-ce dans la norme UTF-8 ?

La possibilite est prevue par Unicode. Mais son usage n'est en rien obligatoire.

Les quelques essais que j'ai fait sous Windows m'ont convaincu qu'il y avait des incoherences dans son traitement, meme dans les programmes fournis par MS.

l'usage des caractères autres que :

http://delahaye.emmanuel.free.fr/spip.php?article6

dans un code source entraine un comportement dépendant de la plateforme.

Ok (mais pas OK avec le "indefini" de ta page; en passant il manque au moins les accolades dans celle-ci).

À noter que "ANSI" est souvent utilisé sous Windows pour désigner la page de code 1252 (qui n'est pas réellement ANSI) et ses sœurs.

Typiquement sous Windows, tout ce qui n'est ni wchar_t, ni dit "OEM" (pages de codes adaptées aux consoles, comme la 437 et la 850) est dit "ANSI".

Y compris les jeux multibytes utilisees dans les versions extreme-orientales?

No comment.

[Médinoc]

Y compris les jeux multibytes utilisees dans les versions extreme-orientales?

No comment.

Je ne sais pas.
Je suppose que c'est le cas pour le paramètre CP_ACP ("current ANSI code page") des la fonctions de conversion char <--> wchar_t de l'API Windows.
Pareil pour des fonctions comme SetFileApisToANSI() vs SetFileApisToOEM().

@Nico_stras: Sous Java et Windows, "unicode" (ainsi que les types wchar_t et java.lang.Char) correspond en fait à UTF-16 (au début, c'était UCS-2). Sur ce forum, j'ai "entendu" parler de systèmes unixoïde où wchar_t correspondait à UCS-4/UTF-32.

wchar_t ne correspond jamais à UTF-8, car UTF-8 est fait pour tenir dans plusieurs char à la place.

[Emmanuel Delahaye]

Ok (mais pas OK avec le "indefini" de ta page; en passant il manque au moins les accolades dans celle-ci).

OK, je mets à jour ...

[Nico_stras]

C'est [ISO 8859-1 qu'il faut utiliser pour les codes sources UNIX]

ok.
Et pour un fichier shell (UNIX), c'est également la norme "ISO 8859-1"

@Nico_stras: Sous Java et Windows, "unicode" (ainsi que les types wchar_t et java.lang.Char) correspond en fait à UTF-16 (au début, c'était UCS-2). Sur ce forum, j'ai "entendu" parlé de systèmes unixoïde où wchar_t correspondait à UTF-32.

wchar_t ne correspond jamais à UTF-8, car UTF-8 est fait pour tenir dans plusieurs char à la place.

C'est à dire ? UTF-16 est aussi soit 8 soit 16 bits? Donc variable

[Jean-Marc.Bourguet]

C'est [ISO 8859-1 qu'il faut utiliser pour les codes sources UNIX

ok.

Oops, j'avais pas remarque. On va se limiter au comportement de gcc sous Linux -- pour les autres compilateurs, voir leur doc, pour plus d'info sur le comportement de gcc, voir sa doc aussi (en particulier la section "Character sets" du manuel du preprocesseur et la section sur les arguments, comme les details varient, prendre la bonne version: http://gcc.gnu.org/onlinedocs/). gcc comme je l'ai deja ecrit a 3 options qui controlent le choix des charsets et le choix par defaut est de prendre celui de la locale en cours. Or sur les Linux modernes (datant de plus de 3/4 ans, Ubuntu par exemple a toujours ete dans ce cas), les locales conseillees pour les francophones utilisent UTF-8. Sur les un peu plus anciens, les locales conseillees pour les francophones europeens utilisaient ISO-8859-15. Il faut remonter a avant l'introduction de l'euro pour que les locales conseillees pour les francophones europeens utilisent ISO-8859-1 (et si on remonte si loin, il vaut mieux verifier aussi le comportement de gcc car ils ont rearchitecture cette partie a un moment).

Et pour un fichier shell (UNIX), c'est également la norme "ISO 8859-1"

C'est quoi un "fichier shell"? Le shell est un programme independant des charsets. Il va utiliser celui de ton terminal. Et pour le charset utilise par la plupart des terminaux, c'est celui de la locale en cours (cfr supra).

C'est à dire ? UTF-16 est aussi soit 8 soit 16 bits? Donc variable

Unicode est le charset. Il est utilise avec plusieurs mecanismes d'encodage (UTF-8, UTF-16, UCS-16, UTF-32/UCS-32). Les wchar_t sont concu pour etre utilise sans mecanisme d'encodage (ce qui en gros correspond a UCS-16, UTF-32/UCS-32 qui ont un mapping 1-1). Si on est puriste, on ne peut pas l'utiliser avec UTF-16 (les gens de Windows et d'AIX ne sont pas puriste a ce point et le font pour des raisons de compatibilite avec des choix faits au moment ou Unicode tenait sur 16 bits; les autres OS ont eu du retard dans l'adoption d'Unicode, mais ca leur a eviter ce piege et ont un wchar_t sur 32 bits plus conforme a l'esprit du C).

Attention, wchar_t n'est pas d'office Unicode (sur Solaris, ca depend de la locale par exemple).

[Médinoc]

@Nico_stras: Non:

• UTF-16 est toujours 16 bits. Seulement, un "code point" d'UTF-16 peut nécessiter deux wchar_t, s'il est supérieur à 65535 (donc, s'il est hors du Basic Multilingual Plane)
  
  • UCS-2 limite à un seul wchar_t, les caractères hors du BMP y sont donc inutilisables.
• UTF-8 est toujours 8 bits, c'est pourquoi tous les "code points" supérieurs à 127 nécessitent 2 char ou plus.
• UTF-32/UCS-4 est 32 bits, donc un code point ne nécessite jamais plus d'un wchar_t (quand ils correspondent à UCS-4/UTF-32).

À cela s'ajoutent les complications dues aux accents, qui font qu'un caractère accentué peut nécessiter plusieurs "code points"...

[Jean-Marc.Bourguet]

Non:

Je suppose que tu t'adresses a Nico_stras et pas a moi.

[LIST][*]UTF-16 est toujours 16 bits. Seulement, un "code point" d'UTF-16 peut nécessiter deux wchar_t, s'il est supérieur à 65535 (donc, s'il est hors du Basic Multilingual Plane)

A noter que Linux, Solaris et d'autres utilisent de wchar_t qui font 32 bits (et y mettent de l'UTF-32/UCS-32 et pas de l'UTF-16). En fait je crois que les seules exceptions sont Windows et AIX (en passant, j'aimerais bien savoir comment ca se passe sur les mainframe base sur de l'EBCDIC, ca ne m'etonnerait pas qu'ils soient aussi plutot UTF-16 qu'UTF-32; 2 raisons: IBM et une certaine sensibilite a l'espace necessaire).

À cela s'ajoutent les complications dues aux accents, qui font qu'un caractère accentué peut nécessiter plusieurs "code points"...

Ce probleme n'est pas neuf avec Unicode, il existait aussi avec ISO 646-FR par exemple (ou certaines lettres accentuees sont representees par lettre BS accent; je sais, l'AFNOR a obsolete toutes ses variantes d'ISO 646-FR et c'est maintenant une copie de 646-IRV).

[Médinoc]

Je suppose que tu t'adresses a Nico_stras et pas a moi.

Tu supposes bien, nos messages se sont croisés.

A noter que Linux, Solaris et d'autres utilisent de wchar_t qui font 32 bits (et y mettent de l'UTF-32/UCS-32 et pas de l'UTF-16). En fait je crois que les seules exceptions sont Windows et AIX (en passant, j'aimerais bien savoir comment ca se passe sur les mainframe base sur de l'EBCDIC, ca ne m'etonnerait pas qu'ils soient aussi plutot UTF-16 qu'UTF-32; 2 raisons: IBM et une certaine sensibilite a l'espace necessaire).

Il me semble que Java aussi utilise UTF-16 sur toutes les plate-formes.
Comme pour Windows, c'était sans doute de l'UCS-2 à la base.
Edit: Wikipédia corrobore.

En fait, je pense que toutes les plate-formes qui utilisent UTF-16 sont parties d'UCS-2.