Discussion :

[kripteks]

Salut à tous.
Je suis vraiment très curieux de savoir si vous développez vos applications en ascii ou vous utilisez wide ou autres ?

Étant débutant.
Sur une simple application en wide je vois que mon code ressemble en rien au code ascii, partout des changements de nom dans les fonctions, on dirait presque un autre langage.

Je viens de voir uchar, ça à l'aire pas mal, on reste plus sur la syntax simple de C.

[Médinoc]

Sous Windows, je suis en TCHAR partout, avec les options réglées pour que ça fasse du Wide.
Hors de Windows, je suis généralement en ASCII étendu, mais vu que de plus en plus de systèmes unixoïdes tournent en UTF-8, il faudrait que je fasse ça aussi (prendre des dispositions spéciales pour les troncatures de chaînes au milieu d'un codepoint, etc.).

[kripteks]

Ce qui est bien pour les français ansi comporte les caractères de base.


Je suis un peu perdu de mon côté:
- ascii (j'ai compris)
- ascii extended (j'ai compris)
- ansi (j'ai compris) (mais ansi == ascii extended ?)
- unicode (si j'ai bien compris, chaque caractère a son code)
- utf-8 (j'ai compris, il comporte au début les même numéros de l'ascii pour les mêmes caractères)

- wchar est dans quelle categorie ?
- quelle est le lien entre l'unicode et l'utf-8 ?

[Médinoc]

"ANSI" sous Windows est un abus de langage. Il signifie généralement ASCII éténdu, mais les encodages ASCII éténdus les plus utilisés par Microsoft (à commencer par Windows-1252) n'ont jamais vraiment été normalisés par l'ANSI.

(ne pas oublier, il y a une pléthore d'ASCII étendus)

---

Unicode est un jeu de caractères dit "universel" qui contient 2¹⁶*17 caractères. UTF-8, UTF-16 et UTF-32 sont des encodages permettant de représenter la totalité des caractères unicode, en utilisant plusieurs valeurs consécutives si nécessaire.

• Sous Linux, l'encodage "wide" correspond à UTF-32, un wchar_t fait donc la taille d'un int 32 bits. Un seul suffit donc toujours à représenter un code point Unicode.
• Sous Windows, l'encodage "wide" correspond à UTF-16, un wchar_t fait donc la taille d'un short. Il en faut un ou deux pour représenter un code point Unicode.
  
  • Il en va de même pour Java et .Net, où un Char fait 16 bits.

UTF-8 est un encodage sous forme d'ASCII étendu: Les code points correspondant aux caractères ASCII (de 0 à 127) prennent tous un char, et les code points strictement supérieurs à 127 prennent de deux à quatre char.

[foetus]

En fait ANSI c'est le code page (ou Multi Byte Character Set, MBCS) par défaut sous Windows ... et donc il est changeant en fonction que tu sois japonais, européen ou russe.

Je remets mon commentaire d'un autre fil de discussion
Unicode c'est UTF-8, UTF-16, UTF-32, ... mais il y en a d'autres (UTF-7 par exemple) obsolètes/ pas utilisés et les variantes Big Endian/ Little Endian.
Et donc

• UTF-8: compatibilité ASCII. Mais pas MBCS.
• UTF-16: compromis entre compatibilité ASCII et taille d'un caractère
• UTF-32: performance

[phi1981]

• UTF-8: compatibilité ASCII. Mais pas MBCS.
• UTF-16: compromis entre compatibilité ASCII/ taille d'un caractère
• UTF-32: performance

Heu ... Je vois pas ce que tu veux dire. UTF-8 est un MBCS.

UTF-16 n'est certainement pas un compromis entre la compatibilité ASCII et la taille d'un caractère, puisqu'il ne permet ni l'un ni l'autre:
- une chaîne ASCII n'est pas directement interprétable comme une chaîne UTF-16
- deux octets ne suffisent pas à représenter TOUT Unicode. Juste une partie nommée le Basic Multilingual Plane.
A ce que je sais, UTF-16 a été utilisé par Microsoft à l'époque où on pensait que 16 bits suffiraient pour représenter tout Unicode. Le résultat c'est que ça marche pas toujours, avec des effets de bords assez difficiles à localiser.

UTF-32: Performances ? vraiment ? Je serais curieux de voir une étude sur le sujet qui démontrerait que utf-32 est plus performant que les autres. Oui, le code est plus simple. Oui, 32 bits correpondent à un mot machine sur de nombreuses architectures. Mais ça ne suffit pas: multiplier par 4 la taille des données à manipuler a aussi un coût lorsque l'on copie une chaîne ou qu'on l'écrit sur le disque. Du coup, je doute fort que ce soit NECESSAIREMENT plus performant.

Edit : Oh, et pour répondre à la question originale, je trouve que la réponse de Médinoc est la meilleure: utiliser TCHAR sous Windows, et de l'utf-8 sous Unix.
Je rajouterais toutefois que lorsque je sérialise du texte (vers un fichier de configuration par exemple), alors je préfère utiliser utf-8 comme format de stockage, et convertir vers du TCHAR au moment de la lecture ou de l'écriture (sous Windows).