Conversion string en UTF-8

Bonjour,

Je cherche désespérément à convertir une chaîne de caractère passé à un programme en UTF-8, or je ne trouve pas d'outils satisfaisant :(

J'ai bien tenté des choses avec "utf8_codecvt_facet" de Boost mais je n'ai pas tellement compris son fonctionnement.

Voici un petit exemple de code :

Code:

---

1 2 3 4 5 6 7

int main (int argc, char **argv) { // traitement sur argv[1] pour le convertir en UTF-8 std::cout << .... << std::endl;   return 0; }

---

Petite précision ma console est configuré pour affiché de l'UTF-8.

Merci d'avance :)

quel systeme d'exploitation?

Windows Seven 32 bits, en fait j'ai un fichier encodé en UTF-8 et j'ai besoin de faire des comparaisons avec les chaînes passé en paramètre de l'application et le contenu du fichier.

je pense qu'il faut utiliser wcout (wide-cout, pour obtenir des wstring) et utiliser WideCharToMultiByte (http://msdn.microsoft.com/en-us/library/aa450989.aspx) en utilisant UTF8 en premier argument

Ok mais je préfère rester en C++ standard et pas pour l'API Windows, car ce programme a aussi pour vocation à être utilisé sur Linux.

Une autre idée ?

Sinon je pense que je vais me rabattre sur Qt si il n'y a pas de solution en standard ou avec boost.

dans ce cas c'est libiconv mais la version win32 je ne sais plus ou la trouver. mais elle existe :) (et pas que la version cygwin)

Moi j'utilise ceci :

Code:

---

1 2 3

std::locale loc( "french"); std::use_facet <std::ctype <wchar_t> > ( loc).widen( & my_string[0], & my_string[size()], & my_wstring[0]);

---

Citation:

---

Envoyé par screetch

dans ce cas c'est libiconv mais la version win32 je ne sais plus ou la trouver. mais elle existe :) (et pas que la version cygwin)

---

J'ai déjà pensé aussi à iconv, mais le problème est que je ne sais pas quel est l'encodage de la chaîne passé en paramètre:aie: et pour utilisé iconv il faut le connaître.

Citation:

---

Envoyé par dragonjoker59

Moi j'utilise ceci :

Code:

---

1 2 3

std::locale loc( "french"); std::use_facet <std::ctype <wchar_t> > ( loc).widen( & my_string[0], & my_string[size()], & my_wstring[0]);

---

---

Ne marche pas, (enfin chez moi), quand je compile ce bout de programme :

Code:

---

1 2 3 4 5 6 7 8 9

int main (int argc, char** argv) { std::cout << argv[1] << std::endl; std::string tmp (argv[1]); std::locale loc( "french"); std::use_facet <std::ctype <wchar_t> > (loc).widen(&tmp[0], &tmp[tmp.size()], &tmp[0]); std::cout << tmp << std::endl;   return 0; }

---

Déjà cela ne compile pas et me dit :

Citation:

---

error: no matching function for call to 'std::ctype<wchar_t>::widen(char*, char*, char*) const'

---

Ensuite en ne gardant que l'instruction :

Code:

---

std::locale loc( "french");

---

J'ai droit à une très belle exception venant de la lib C++ me disant que le nom de cette locale n'existe pas, j'ai donc fouillé un peu et j'ai vu qu'il n'y a que 3 paramètre possible pour le type de locale qui sont :

• ""
• C
• POSIX

Voila, j'espère avoir été clair dans ce qui ne marchait pas;) Mais merci en tout cas :)

Citation:

---

Envoyé par snake264

Ensuite en ne gardant que l'instruction :

Code:

---

std::locale loc( "french");

---

J'ai droit à une très belle exception venant de la lib C++ me disant que le nom de cette locale n'existe pas, j'ai donc fouillé un peu et j'ai vu qu'il n'y a que 3 paramètre possible pour le type de locale qui sont :

• ""
• C
• POSIX

---

La liste des locales disponible dépend en fait du compilateur, ce n'est pas portable. Par exemple, sous windows avec visual C++, la chaîne "French_France" est acceptée.

A ok, je ne le savais pas, je ne prendrais donc pas cette solution... Je vais voir avec iconv si j'arrive à trouver l'encodage de ma chaîne que je cherche à traduire:aie:

Ou sinon je vais me rabattre sur Qt, tant pis.

glib a des fonctions pour récupérer l'encodage courant. Et c'est assez horrible. Il n'y a pas de solution vraiment portable apparemment a part un framework comme Gtk+ ou Qt :(

Il y a boost.locale qui est proposée dans boost et qui visiblement pourrait résoudre ton problème.

Beaucoup plus léger (et facile a intégrer) : UTF8CPP que j'ai déjà utilisé avec succès. Par contre vu la légèreté du code, je ne sais pas si ça règle "tous" les cas de conversion.

A mon avis, tu chopes UTF8CPP, tu utilises une fonction de conversion, et hop c'est réglé.

C'est bon j'ai résolu mon problème en utilisant Qt, c'est bourrin mais bon je pense que c'est malgré tout la meilleur solution au lieu de mélangé des tas de librairies autant en utiliser qu'une et profiter de tout ce qu'elle peut offrir:mrgreen:

Merci à vous:ccool:

Ben si tu utilises Qt dés le départ pour d'autres choses, oui, mieu vaut chercher là en premier...

Si tu utilises Qt juste pour ça par contre... :aie:

Justement je faisais tout avec la STL pour le moment...

Donc maintenant comme j'utilise Qt je vais tout traduire en Qt de cette manière je ne l'utiliserai pas que l'encodage:mrgreen: mais bonjour le boulot:aie:

...


Donc ça serait pas plus simple de garder ton algo STL et ajouter UTF8CPP?

Qt c'est quand même tout un environnement hein...

Cette bibliothèque ne me permet pas de faire ce que j'attends.

Et pour Qt il faut juste que je remplace certains types et méthodes de la STL par ceux de Qt ça demande tout au plus une petite demi journée de boulot ensuite revérifier que mes TU fonctionnent et ça sera bon:ccool:

Et puis ça fait casiment 1 an que j'ai pas retouché à Qt ça me fait une bonne raison pour m'y remettre:mouarf:

pourquoi tu ne veux pas garder ton code utilisant la STL?

en fait moi j'ai fait le contraire de toi, j'utilisais beaucoup Qt meme dans mon backend... jusqu'a cette annonce de Nokia qui m'a fait d'un coup repenser que le backend devrait etre le plus independant possible d'un framework.
Je suis donc en train de remplacer mes QVector et mes QStringList par std::vector and std::vector<std::string>
:aie:

Tout simplement parce que la STL ne permet pas de faire ce que je souhaite ;)

tu aurais un exemple?

Voir mon premier post, la STL n'a pas de fonction me permettant de faire ce que je souhaite, il faut que je la créé moi même et j'avais un peu la flemme:aie: donc autant utiliser ce qui existe déjà:ccool:

STL = string pour toi?

ok dans ce cas, mais en fait je suis aussi en train de changer de QString en std::string. Je n'ai pas de traitement vraiment sur les chaines...

Heuu non pas vraiment, STL = Standard Template Library, qui est la bibliothèque standard C++ normalisé par l'ISO.

D'ailleurs un petit conseil si Qt est trop gros pour toi utilise la bibliothèque Boost qui offre plus de possibilités que la STL et est plus performante.

Car malheureusement la STL est pratique mais extrêmement limité:mrgreen:

je ne comprends pas du tout
en quoi la STL est limité par rapport à Qt?

Qt permet de faire énormément plus de choses que la STL et pour type équivalent (par exemple QVector et std::vector puis QString et std::string etc.) ceux de Qt sont beaucoup plus performant. Idem pour Boost ;)

prenons QVector par exemple,
que permet-il de plus que std::vector?

Pour cela à toi de lire la doc, je ne vais pas tout résumer ici:aie:

http://qt.developpez.com/doc/latest/qvector/

Mais mis à part certaines méthodes en plus le type est surtout comme je l'ai déjà dit plus performant (donc plus rapide pour la gestion des vecteurs qu'un simple std::vector). Pour voir cela je te laisse aussi le soin de faire des tests de comparaisons de performances.

Mais encore une fois utiliser Qt est un choix conséquent, pour un choix aussi performant mais moins lourd il y a la bibliothèque Boost.

Boost ne propose pas de vector (ou équivalent avec un autre nom) tout simplement parce que eux savent ce qu'est le NIH...

Bref dans du code métier il ne devrait jamais y'avoir de classe en Q quelque chose (des classes qui viennent de Qt quoi). Réserve ça à l'interface un point c'est tout.

Si il en propose :

http://live.boost.org/doc/libs/1_46_...doc/vector.htm

On est pas obligé d'utiliser Qt pour faire que du graphique il existe aussi beaucoup d'applications qui utilisent Qt et qui sont juste des application console;)

Après c'est chacun fait comme il le sent. Perso pour moi ni boost ni la STL n'offraient ce que je voulais sans faire moi même les méthodes je me suis donc rabattu sur Qt et mon appli n'est aucunement graphique:mrgreen:

Non, le lien que tu me donnes c'est un vector au sens mathématique du terme et non au sens de la collection d'objets comme celui de la STL. (qui est mal nommé à mon avis).

as-tu fait des benchmarks pour dire que QVector est plus performant que std::vector?

et pourrais-tu me donner un exemple que sait faire QVector et pas std::vector?
juste un seul ca me suffira.

comme a dit Goten, boost ne propose pas de vector ou list pour remplacer std::vector ou std::list.

Elle est pourtant définie comme un container :

http://live.boost.org/doc/libs/1_46_...ept.htm#vector

Mais c'est vrai que c'est pour un usage mathématique pour l'algèbre linéaire, je suis bien d'accord avec toi et me suis mal exprimé, je m'en excuse donc:oops:.

Mais d'après la doc je ne vois pas ce qui peut empêcher de s'en servir comme vecteur au sens collection. En créant des méthodes soit même. Mais il est vrai que ça fait du boulot:aie:

Enfin perso je ne l'ai jamais utilisé avec boost j'utilise "Boost.Array" qui me permettent de remplacer largement std::vector, std::list, std::queue, etc. Avec des classes perso que je me suis faites moi même.

Désolé epsilon je n'avais pas vu ton message:oops:

Pour le benchmark et les quelques différences je te renvoi à cet article :

http://doc.qt.nokia.com/qq/qq19-containers.html

mais le lien explique comment les containers de Qt marche, la mécanique interne.

il n'y a pas de benchmark, ni meme d'explication sur ce que pourrait faire QVector en plus de std::vector.

mais alors que t'apporte QVector sur std::vector dans ton cas?
je demande juste un seul exemple, pas plus.

La doc que je t'ai donnée donne quelques différences entre les deux.

Sinon la plus grosse différence se fait par le nombre de méthodes proposées typiquement :

append, constData, contains, data, endswith, replace, etc.

Qui sont autant de méthodes très pratique et que l'on utilise quasiment à chaque fois et qu'avec Qt on n'a pas à recoder.

C'était un exemple parmi d'autres. Si tu veux vraiment avoir des exemples lis les 2 docs que je t'ai donné tu aura déjà une bonne idée sur les différences;) Je te conseil aussi de lire la doc de std::vector en complémentaire.

Citation:

---

Envoyé par snake264

C'était un exemple parmi d'autres. Si tu veux vraiment avoir des exemples lis les 2 docs que je t'ai donné tu aura déjà une bonne idée sur les différences;) Je te conseil aussi de lire la doc de std::vector en complémentaire.

---

Pour savoir ce que la STL permet de faire avec les std::vector (ou avec tout autre de ces containers d'ailleurs), il faut non seulement lire la doc correspondant à std::vector mais aussi (et surtout) celle sur les algorithmes. En effet, la STL est conçue de manière à proposer peu de traitement en tant que méthode membre des container mais par contre plusieurs algorithmes qui travaille sur des paires d'itérateurs (les algorithmes étant décorrélés des containers).
Bref la STL ce n'est pas juste des containers mais bien le trio container + itérateurs + algorithmes.

Un petit extrait de cette doc :

Citation:

---

Whereas STL's containers are optimized for raw speed, Qt's container classes have been carefully designed to provide convenience, minimal memory usage, and minimal code expansion. For example, Qt's containers are implicitly shared, meaning that they can be passed around as values without forcing a deep copy to occur. Also, sizeof(QXxx) == sizeof(void *) for any Qt container, and no memory allocation takes place for empty containers.

Qt's containers fully take advantage of partial template instantiation to provide different implementations depending on the data type that is stored. Qt solves the code expansion issue that arises in conjunction with C++ templates by putting most of the container code in non-template internal classes such as QListData and QMapData, making Qt's containers particularly well suited for embedded programming.

---

Donc, déjà, c'est moins performant, ils le disent eux-même.

Ensuite, le COW, ça cause plein de problèmes quand on essaye de travailler en multithread. Les std::string du C++ étaient prévue pour qu'une implémentation COW soit possible, et à un moment, la plupart des gens utilisaient une telle implémentation. Mais les benchs ont montré que c'était plus une pessimisation qu'autre chose, de moins en moins de gens les ont utilisés, et désormais en C++0x, il n'est plus possible d'avoir du COW pour les strings. De plus le principal use case pour le COW qu'ils citent (passer par valeur à coût réduit) me semble peu justifié (il suffit de passer par référence constante, et on a pareil, mais sans COW, sans lock, sans rien).

Le fait de ne pas avoir d'allocation pour un conteneur vide est aussi probablement vrai dans toutes les implémentations de la STL (du moins pour vector).

Pour le coup du code bloat, Bjarne a depuis toujours sur son site un bout de code qui montre comment l'éviter pour les std::vector en utilisant une spécialisation sur T*. Rien de nouveau donc sous le soleil. Je ne sais pas dans quelle mesure toutes les implémentations utilisent ou pas cette technique.

Je ne dénigre pas Qt, je pense qu'en C++, on n'a probablement pas mieux pour faire de l'IHM actuellement. Mais leur choix de refaire ce qui existe ailleurs, peut-être justifiable dans la version 1 de la biblitohèque, quand la STL n'était pas assez stable sur toutes les plateformes, ne me semble pas très pertinent en nos jours.

(ps : Je ne pense pas qu'Epsilon ait vraiment besoin de lire la doc de std::vector)

Pour en revenir au problème initial, en fait la solution que j'ai proposée fonctionne (je m'en sers sous Windows, avec VS2008 et MingWin, et sous Linux avec GCC) mais en ne mettant aucun argument au constructeur de std::locale, du coup il utilise la locale globale:

Code:

---

1 2 3

std::locale l_loc; std::use_facet <std::ctype <wchar_t> >( l_loc).widen( & my_string[0], & my_string[size()], & my_wstring[0]);

---

Sinon, pour l'erreur de compilation que tu rencontrais, à part #include <locale>, je ne vois pas pourquoi ça ne compile pas

chez moi ton code utilise la locale C qui est ascii 7 au lieu de cp1252 (europe du nord) je crois

Et la conversion est correcte ou pas ? (à tester avec un texte à accents)