Version imprimable
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.
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.).
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 ?
"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 216*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.
En fait ANSI c'est le code page (ou Multi Byte Character Set, MBCS) par défaut sous Windows :mrgreen: ... 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 :wow:
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 :mrgreen:
- UTF-8: compatibilité ASCII. Mais pas MBCS.
- UTF-16: compromis entre compatibilité ASCII et taille d'un caractère
- UTF-32: performance
Heu ... Je vois pas ce que tu veux dire. UTF-8 est un MBCS.Citation:
Envoyé par foetus
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).
Regardes bien la page Wiki UTF-8: il y a des caractères sur 4 octets :mrgreen:, contrairement aux MBCS qui ont des caractères soit sur 1 octet soit sur 2, pas plus.Citation:
Envoyé par phi1981
Justement le problème de l'UTF-8 c'est qu'en étant compatible ASCII, certains caractères (notamment asiatiques) sont codés sur 3 ou 4 octets.Citation:
Envoyé par phi1981
Je sais tu n'es pas asiatique :mrgreen:
Alors que l'UTF-16 propose pour ce problème des caractères souvent plus petits.
Et l'UTF-16 n'est pas compatible ASCII, mais tu peux lire les caractères ... mais avec un caractère bidon entre :mrgreen:
Citation:
I believe there are a lot of good articles about this around the Web, but here is a short summary.
Both UTF-8 and UTF-16 are variable length encodings. However, in UTF-8 a character may occupy a minimum of 8 bits, while in UTF-16 character length starts with 16 bits.
Main UTF-8 pros:
Basic ASCII characters like digits, Latin characters with no accents, etc. occupy one byte which is identical to US-ASCII representation. This way all US-ASCII strings become valid UTF-8, which provides decent backwards compatibility in many cases.
No null bytes, which allows to use null-terminated strings, this introduces a great deal of backwards compatibility too.
Main UTF-8 cons:
Many common characters have different length, which slows indexing and calculating a string length terribly.
Main UTF-16 pros:
Most reasonable characters, like Latin, Cyrillic, Chinese, Japanese can be represented with 2 bytes. Unless really exotic characters are needed, this means that the 16-bit subset of UTF-16 can be used as a fixed-length encoding, which speeds indexing.
Main UTF-16 cons:
Lots of null bytes in US-ASCII strings, which means no null-terminated strings and a lot of wasted memory.
In general, UTF-16 is usually better for in-memory representation while UTF-8 is extremely good for text files and network protocols.
Disons qu'il y a une différence entre la signification du sigle MBCS et ce que Windows appelle "MBCS".
Windows possède des fonctions pour convertir entre UTF-16 et la plupart des encodages 8 bits, y compris UTF-8, mais ne peut pas travailler "directement" en UTF-8, car ses fonctions de texte sur char reposent sur le fait que "MBCS" ne code jamais un caractère sur plus de deux char; et changer ces fonctions briserait la compatibilité pour les programmes.
Pour être précis, à l'époque où l'on pensait que 16 bits seraient suffisant, Windows et Java utilisaient UCS-2, pas UTF-16.Citation:
Envoyé par phi1981
UTF-16 a été créé en réponse à l'extension d’Unicode de 16 à 20.1 bits, car il était trop tard pour passer wchar_t sur 32 bits.
La correspondance "wchar_t == char + 1 octet" marche pour ASCII et pour ISO-8859-1 qui préfixes d'Unicode, mais ça ne marchera pas pour les autres ASCII étendus, y compris Windows-1252.Citation:
Et l'UTF-16 n'est pas compatible ASCII, mais tu peux lire les caractères ... mais avec un caractère bidon entre
Merci pour les réponses.
J'aimerais juste être sûr d'avoir bien compris ceci:
- un wchar_t, c'est 32 bits
- chaque caractère dans l'unicode à son code point fix
- un wchar_t est suffisant pour accepter chaque code point de l'unicode, sans avoir besoin d'autre octet en plus
Sous Unix, oui. Sous Windows c'est 16 bits, et donc parfois tu peux avoir besoin de deux "wchar_t" pour composer un code point Unicode.Citation:
- un wchar_t, c'est 32 bits
- un wchar_t est suffisant pour accepter chaque code point de l'unicode, sans avoir besoin d'autre octet en plus
La plupart des gens répondraient "oui" mais malheureusement c'est un peu plus compliqué, ça dépend de ce que t'appelle un "caractère". Par exemple, certains symboles accentués sont représentés par deux code points : un pour le caractère lui-même, un autre pour l'accent.Citation:
- chaque caractère dans l'unicode à son code point fix
Cela a une influence par exemple si tu essayes de compter les caractères d'une chaîne : un algorythme naïf pourrait compter simplement le nombre de code points dans la chaîne. Mais un humain dirait que le caractère accentué ne représente qu'un seul caractère !
C'est un TRES vaste sujet.
Exact, merci.Citation:
Envoyé par Médinoc
Aie aie, va falloir étudier encore :(
Mais pour le moment ça me va, étant sous linux.
Heureusement, on a rarement vraiment besoin de connaître le nombre de caractères d'une chaîne. Généralement en informatique, on a surtout besoin du nombre de char/wchar_t qu'il faut pour la stocker (avec le caractère nul, dans le cas du C).
Et pour l'affichage, on a généralement plutôt besoin de la largeur en pixels de la chaîne dans une police donnée que du nombre de caractères, leur largeur n'étant généralement pas fixe (surtout quand on sort des caractères latins: il me semble avoir entendu dire que les idéogrammes chinois étaient en double largeur dans certaines polices supposément à chasse fixe).
Justement moi je cherchais à connaître le nombre de caractères d'une chaine.
Seul chose que j'ai pu trouvé qui me conduira au bon résultat, c'est de faire une boucle avec une addition.
Il existe des fonctions j'imagines, mais ces fonctions ou plutôt leurs noms et leurs fonctionnements dépende énormement du codage de caractère.
Il y a télément de chose à prendre en compte à cause de ces caractères, c'est pour cela j'aimerais choisir le bon codage une bonne fois pour toute, mais étant débutant j'ai vraiment du mal.
J'y suis même allé jusquà penser utiliser de l'utf-32 car il utilise le code point sur un 32 bits directement, terminant le doute d'avoir des octets en moins ou en plus, mais hélas encore ce windows mélange..
Pour le "nombre de caractères", il faut alors garder à l'esprit:
- Un accent combinant ne doit probablement pas compter comme "caractère", vu qu'il s'ajoute au précédent.
- Un espace de largeur nulle (sécable ou non) doit-il compter comme un "caractère"?
etc.
Une méthode intéressante serait de te faire une fonction int ReadCodePoint(char const *str, size_t *pOffset) qui lirait un codepoint UTF-8, te retournerait sa valeur unicode complète, et avancerait l'offset dans le buffer en conséquence. Ensuite, tu n'as plus qu'à gérer les considérations ci-dessus.