Unicode est-il vraiment un probleme ?

**epsilon68** · 28/08/2006, 14h16

n'y a-t-il que moi pour penser que d'avoir les char ou les wide chars ne suffit pas ?

J'aime vraiment l'idée d'avoir une classe qui gere de l'unicode en interne, mais permet de convertir en 8 bits ou UTF-8 etc....

on ne serait pas obligé de savoir a l'avance ou de se dire que ca peut-etre pas marcher dans ce cas etc...

a+

**loufoque** · 28/08/2006, 14h39

n'y a-t-il que moi pour penser que d'avoir les char ou les wide chars ne suffit pas ?

Non, il y a probablement d'autres personnes qui ne connaissent pas vraiment grand chose à unicode qui pensent de même.

**epsilon68** · 28/08/2006, 14h40

Envoyé par loufoque

Non, il y a probablement d'autres personnes qui ne connaissent pas vraiment grand chose à unicode qui pensent de même.

MOUAA AH AH
merci....

**epsilon68** · 28/08/2006, 14h57

alors que me conseilles-tu Mr. Loufoque ?

tout faire avec des std:string ?
tout faire avec des std:wstring ?
ne pas m'occuper d'unicode ?

explique moi ta "strategie" s'il te plait...

**Médinoc** · 28/08/2006, 15h21

Sous Visual, je conseillerais tout en wstring ou tout en std::basic_string< TCHAR >, c'est selon.

Sous MinGW, ça peut être plus dur, puisque les wcin/wcout ne sont pas supportés.

**epsilon68** · 28/08/2006, 15h54

Envoyé par Médinoc

Sous Visual, je conseillerais tout en wstring ou tout en std::basic_string< TCHAR >, c'est selon.

Sous MinGW, ça peut être plus dur, puisque les wcin/wcout ne sont pas supportés.

en fait j'aimerais le faire d'une maniere multiplateforme ....
comme dit, avec Qt c'est transparent, mais je cherche un moyen avec boost, vu que tout le monde sur ce forum au moins, me conseille boost pour la partie metier ...

peut-etre que Loufoque aurait une idée, puisqu'il comprend bien le probleme d'unicode ?!

**Jean-Marc.Bourguet** · 28/08/2006, 16h55

Envoyé par epsilon68

n'y a-t-il que moi pour penser que d'avoir les char ou les wide chars ne suffit pas ?

Ça dépend pour quoi faire. Personnellement, j'aimerais bien en standard quelque chose qui offre au moins les informations de classifications et de normalisation des formes, et pour ça il faut un peu plus même si on peut imaginer une interface basée sur les locales et char/wchar_t.

Pour certains usages, il est vraissemblable que la situation actuelle suffise, pour autant qu'il y ait la locale nécessaire. Mais même alors, un problème est que le nom des locales n'est pas normalisé. Et pour pas mal d'usage, il faudrait au moins des facettes de conversion supplémentaires.

En pratique, les locales sont quelque choses de complexe, et on peut désirer un support plus simple. D'ailleurs certains sont suffisemment convaincus pour préparer des propositions: N2018 N2035 même si ces propositions ne vont pas aussi loin que je le voudrais. Et ce sont des propositions relativement avancées dans le processus (voir N2011)

**loufoque** · 28/08/2006, 17h37

Il y a plusieurs moyens de gérer l'unicode, et le choix que l'on retient dépend en fait surtout de l'interfaçage dont on a besoin avec d'autres bibliothèques ou le système.
Quoi qu'il en soit je suis plutôt pour une solution indépendante du système et des locales en dehors des interfaçages. Donc bien entendu, rien de basé sur les caractères larges.
Pour des raisons d'interfaçage avec des bibliothèques utilisant beaucoup std::string on peut mettre de l'utf-8 dans des std::string tout en faisant attention à ce que l'on fait, en particulier on peut utiliser un itérateur externe spécial. (disponible dans boost, qui propose aussi un convertisseur utf-8 <-> ucs-4)

Sinon un type dédié c'est mieux.
De toutes façons dans l'idéal il pourrait être bon de revoir std::string, on pourrait en profiter pour refaire quelque chose supportant bien l'unicode.

**JolyLoic** · 28/08/2006, 23h20

Envoyé par loufoque

Quoi qu'il en soit je suis plutôt pour une solution indépendante du système et des locales en dehors des interfaçages. Donc bien entendu, rien de basé sur les caractères larges.

J'ai du mal à suivre ton "donc". Pourrais-tu développer ?

**loufoque** · 29/08/2006, 03h03

La taille des caractères larges et le charset utilisé dépendent du système et, éventuellement, des locales.
C'est donc on ne peut plus clair.

**JolyLoic** · 29/08/2006, 07h58

La taille des caractères non large dépend aussi du système. Le charset aussi.

**epsilon68** · 29/08/2006, 11h39

et libiconv ?

mais je ne sais quoi prendre comme representation interne et comment utiliser iconv dans le cas d'un fichier par exemple ?

**epsilon68** · 30/08/2006, 09h13

et libiconv ?
l'avez-vous deja utilisé ?
Grace a cet lib on pourrait toujours fonctionner en unicode en interne, et sortir dans un encoding quelquonque non ?

**epsilon68** · 30/08/2006, 12h58

heu ... ?
vous n'utilisez pas libiconv ?
pourtant il fait les conversions, beaucoup de conversion.

moi je n'ai pas d'experience dedans, mais j'aimerais bien quelques pistes, strategies a employer si on veut travailler avec avec unicode.

merci a+

**epsilon68** · 02/09/2006, 00h05

J'ai utilisé iconv pour tester.
J'ai lu un fichier XML codé en UTF-8 et un autre codé en Unicode UTF-16

J'ai du tester errno pour savoir si la conversion avait echouée a cause d'un caractere incorrect ou alors une sequence incomplete. sinon a part aussi une logique pas si evidente que ca, ca marche plutot bien.
bon le code resultant necessiterait vraiment de l'encapsulation ....

j'ai aussi testé cela avec Qt, wahoo vraiment simple.
dans le genre QTextStream in( ... ); in.setEncoding("UTF-8")
apres c'est tout bon

Le truc c'est que plus je m'ecarte de Qt, plus j'aurais envie de refaire ce genre de classe.... un "char" unicode, un stream qui gere les encoding etc...

Je me demandais aussi si le fait de tester "errno" dans le cadre multi-thread ne posait pas de probleme ? errno est-il une variable global ou uniquement au thread ?

et vous qu'en pensez vous ?
le probleme avec tout cela c'est que penser aussi aux expressions regulieres ainsi qu'a tous les traitements de chaines en unicode... ca peut tres vite devenir tres complexe !!!!

... je ne sais plus quoi penser des std::string, de boost et de Qt
avec cette histoire d'unicode ....

**loufoque** · 02/09/2006, 12h10

En fait je travaille sur un nouveau type de string qui, entre autres, fonctionnerait en Unicode et que j'aimerais bien soumettre à boost.
Malheureusement j'ai encore du mal à voir comment tout cela peut s'interfacer sans trop de problèmes avec l'existant. Pour l'instant, je serais pour traiter std::string comme étant dans le charset local et donc faire des conversions de charset pour la construction depuis std::string ou la conversion vers std::string, ce qui me semble être une opération coûteuse.
Sinon y'a la solution Glib::ustring

**zais_ethael** · 02/09/2006, 17h33

Une petite question:
pour ce qui est des string et char*, l'encodage est dépendant de la plateforme ca tout le monde le sait. Mais dans le cas des wstring, ce n'est pas sensé être du pur utf-16, donc strictement similaire sur toutes les plateformes? (je parle uniquement du stockage en mémoire, pas des flux)

**Jean-Marc.Bourguet** · 02/09/2006, 18h05

Envoyé par zais_ethael

Une petite question:
pour ce qui est des string et char*, l'encodage est dépendant de la plateforme ca tout le monde le sait. Mais dans le cas des wstring, ce n'est pas sensé être du pur utf-16, donc strictement similaire sur toutes les plateformes? (je parle uniquement du stockage en mémoire, pas des flux)

Ça peut être des codages larges autres (du genre de ceux utilisés par les Japonais, les Chinois, les Koréens depuis avant Unicode -- JIS, Big5, ...)

**loufoque** · 02/09/2006, 18h08

Mais dans le cas des wstring, ce n'est pas sensé être du pur utf-16, donc strictement similaire sur toutes les plateformes?

Non.
Non seulement ça a déjà été dit dans ce sujet, mais en plus tu as des preuves vivantes que c'est faux. La taille de wchar_t varie d'un système à l'autre (2 octets sous MS Windows, 4 sous GNU/Linux). Ensuite wstring est normalement censé contenir des charsets de taille fixe, ce que n'est pas UTF-16.
Et pour finir, aucune partie de C++ n'a la moindre notion de ce qu'est Unicode. Quelques vagues notions seront probablement ajoutées dans C++0x, et mieux si on de la chance.

**Jean-Marc.Bourguet** · 02/09/2006, 18h41

Envoyé par loufoque

Et pour finir, aucune partie de C++ n'a la moindre notion de ce qu'est Unicode.

D'Unicode, faut pas rêver. Mais de ISO-10646, il y a quelque chose. uXXXX et UXXXXXXXX. Et il semble évident que dans une locale ISO-10646, wchar_t doit faire au moins 21 bits. Le problème, c'est que la gestion des jeux de caractères est trop couplée au reste des locales (ou que tout est trop couplé dans les locales).

Unicode est-il vraiment un probleme ?

C++

Discussions similaires

Partager

Partager