Unicode, éclaircissement et aide

Bonsoir,

J'ai voulu insérer dans un programme en C (sous Windows) le symbole ≤ (<= si ça s'affiche pas).

J'ai d'abord essayé sans changer le reste de mon code, et ça affichait un peu n'importe quoi, j'ai donc compris qu'il fallait utiliser le truc que je ne maitrisais pas du tout, les "wchar_t" (Unicode apparemment).

Donc, j'ai changé le type des char en wchar_t, les textes "" en L"" et ainsi de suite pour en finir par afficher la chaine de caractères avec MessageBoxW.

Ça marche bien pour la boite de dialogue concernée, mais tous les autres textes du programme affichent n'importe quoi à la place des caractères accentués.

Je pensais m'en sortir sans changer le reste du programme, mais visiblement ça ne marche pas ...

Donc, est-ce que j'aurais loupé un truc et ce que je veux faire (mettre juste une phrase en Unicode parmi de l'ASCII) est possible ?
Ou faut-il mettre tout le programme en Unicode ? (#define dans le(s) header(s) ?)

Sinon, l'Unicode est pas défaut sur les OS Microsoft à partir de Windows 2000 et XP, c'est bien ça ?

Est-ce que vous connaissez un bon cours sur les codages (c'est comme ça qu'on dit ?) en relation avec la programmation ?

Merci.
Pierre.

Eh bien typiquement sous Windows, pour éviter d'avoir à convertir tout le programme quand on passe en unicode, on code tout dès le début en utilisant des TCHAR à la place des char et des wchar_t.

TCHAR au lieu de char, LPTSTR au lieu de char*, LPCTSTR au lieu de const char *, et au lieu des fonctions de <string.h>, on utilise celles de <tchar.h>.
Et ainsi, on n'a plus qu'à changer deux defines (ou simplement une option de compilation sur un Visual récent) pour tout passer en unicode.

Là où l'on a toujours quelques problèmes, c'est pour les accents sur la console (il reste des trucs un peu compliqués). Mais hors de la console, le passage à l'unicode est censé résoudre tous les problèmes...

Merci bien pour cette réponse.

Expliqué clairement ça devient effectivement plus simple, si ça se trouve dans un peu de temps ça me fera moins peur tout ça ...

Par contre, TCHAR c'est pas standard, c'est bien seulement sous Windows ?

Si oui, et si les systèmes qui ne supportent pas l'unicode deviennent rares, il vaut mieux directement utiliser des wchar_t ?

Concrètement, il faut mettre #define UNICODE puis passer tous les char en wchar_t ainsi que toutes les chaines "" en L"" et toutes les fonctions standards str* en wcs* ?

Pour les chaines "", il faut rajouter L, mais pour les caractères uniques, il faut faire L'' aussi ?

Merci.
Pierre.

1. Non, ce n'est pas standard, c'est uniquement pour Windows. Mais avec les bons defines et typedefs, tu peux faire compiler ça en non-unicode ou en non-unicode sur une plate-forme standard...
2. Ah non, pas du tout! Tu loupe toute l'utilité des TCHAR!
   
   • Déja, si tu fais tout en unicode, tu n'as pas besoin de #define UNICODE ni de #define _UNICODE (à moins que tu n'utilises les MFC): Ces deux macros n'affectent que les TCHAR.
   • Ensuite, quand tu utilises les TCHAR, tu dois tout passer en TCHAR, les chaînes "" en TEXT("") ou _T(""), et toutes les fonctions str* en _tcs*. Pour les caractères uniques aussi.

Le header tchar.h, fournit par le SDK windows (donc fournit sur les plateformes windows) permet de rédiriger les types caractères et les fonction de manipulation de caractères vers les versions ansi ou unicode en fonction d'un seul define.

Tu peux très bien créer un header tchar.h sous linux par exemple et récupérer la plupart des defines du tchar.h de MS (avec adapations car il y a des entrées pour des fonctions non standard et certaines exclusives MS ainsi que des types MS).

Comme le dis Médinoc, cela permet d'avoir un code portable.

Par exemple, je compile mes librairies sous VS2005 (Windows) et GCC (Linux - OpenSuse) en ansi ou en unicode en définissant une seule macro. Le code est donc le même pour tout les builds et indépendant du charset et de la plateforme.

La seule chose à laquelle il faut faire gaffe, c'est la taille d'un caractère (pour la gestion dynamique de buffer) qui peut être généralement (ce n'est pas une régle absolue) :

• 1 (char)
• 2 (wchar_t sous MS et certaines implémentation unix-like)
• 4 (wchar_t en fonction des implémentations unix-like)

Sinon par rapport à ta question :

Citation:

---

Sinon, l'Unicode est pas défaut sur les OS Microsoft à partir de Windows 2000 et XP, c'est bien ça ?

---

Windows NT 3.5, 4, 5(2000/XP), 6 (VISTA) gère nativement uniquement les chaînes de caractère en unicode (UTF16 - taille de caractère sur 2 octets).
Donc, sous cet OS, toute les chaines ANSI fournies aux / récupérées des API Win32 sont donc converties en unicode par le kernel pour ses traitement internes

OK, merci à vous deux pour ces précisions.

Si l'unicode n'est valable que sous Windows, qu'utilise-t-on pour afficher des caractères non-ASCII sous Linux par exemple ?

Merci.

Citation:

---

Envoyé par Pierre.g

Si l'unicode n'est valable que sous Windows, qu'utilise-t-on pour afficher des caractères non-ASCII sous Linux par exemple ?

---

Unicode n'est seulement valable que sous windows...

Bien au contraire, la plupart des OS supporte Unicode !

Tu devrais lire cette page, cela devrait être plus clair pour toi après

Merci pour ces explications.

Vous venez de m'éclairer sur un truc qui me faisais un peu peur.

Pierre.

Pour la mise au point de mon système d'exploitation (cf. forum assembleur) je me suis beaucoup servi de ceci
http://hapax.qc.ca/
Je vous recommande "BabelMap" comme outil de test et de compréhension.