Gérer et comparer des chaînes UTF-8 provenant de fichiers.

Bonsoir,

Voilà la situation, j'ai en input un fichier texte délimité utilisant l'encodage utf-8. Mon algo doit le charger en mémoire et effectuer des comparaisons d'égalité entre les différentes chaînes afin de repérer des similarités de différents types.

Mon gros problème, c'est de savoir comment je pourrai stocker ces chaînes en mémoire de façon à pouvoir dans un premier temps les découper puis ensuite les comparer.

J'ai pensé au départ à utiliser des wstring et wchar_t simplement, mais d'après ce que j'ai appris, dans GCC c'est implémenté sous forme d'UCS-4 (4 bytes par caractères!) ce qui me semble très inefficace vu la quantité que je dois en gérer, sans parler des comparaisons...

En fait vu que la valeur est sans grande importance et que seuls les bytes m'intéressent, j'ai pensé à utiliser de simple char[] contenant les octets bruts mais je ne sais pas trop comment ça va réagir lorsque j'enfilerai ça dans des boost::unordered_set (je sais pas si ça se hash tellement bien que ça).

En fait je sais pas trop comment m'y prendre avec ces chaînes au format UTF-8, sachant que le code doit être portable linux et windows.

Bref si vous avez des conseils, sachant que ça doit être assez efficace, je suis preneur.

Pourquoi ne pas convertir tout simplement ces chaînes vers autre chose que de l'UTF-8, par exemple de l'ISO-8859-1, afin de ne plus avoir à trop te préoccuper des caractères multi-octets ?

Hello,

Merci de la réponse. Mon algo doit être capable de gérer des caractères exotiques. Pour l'instant, après avoir pédalé dans la semoule un bon moment, j'ai choisi d'utiliser QT.

Le fichier source peut être lu assez facilement et transformé à la volée:

Code:

---

1 2 3 4 5 6 7 8 9 10

QTextStream in(&file); in.setCodec( "UTF-8" );   while (!in.atEnd()) {   QString line = in.readLine(); ... }

---

Les QString sont des chaînes unicode sur 2 octets qui possèdent un tas de fonctionnalités assez commode. Je doute que ce soit le meilleur choix possible mais ça me semble pas si mal comme compromis entre des raw char[] et du wstring.

Pourquoi tu n'utilises pas tout simplement std::string ?
Tu lis tes données directement, et tu manipules ta chaîne en UTF-8. Utiliser QString n'apporte strictement rien. Dans les deux cas, le découpage et la comparaison ont les mêmes propriétés.

Citation:

---

Envoyé par loufoque

Pourquoi tu n'utilises pas tout simplement std::string ?
Tu lis tes données directement, et tu manipules ta chaîne en UTF-8.

---

Bah il paraît qu'il y a un boost.unicode qui est déjà bien avancé :roll:

Citation:

---

Envoyé par loufoque

Pourquoi tu n'utilises pas tout simplement std::string ?
Tu lis tes données directement, et tu manipules ta chaîne en UTF-8. Utiliser QString n'apporte strictement rien. Dans les deux cas, le découpage et la comparaison ont les mêmes propriétés.

---

Oui mais qu'est-ce que je fais des caractères sur plusieurs octets? Avec des QString je peux faire toutes les manipulations de texte (tokenization, regex) de façon sûre, tandis qu'avec un std::string, je suppose que la plupart des API ne tiendront pas du tout compte du fait que plusieurs chars peuvent en réalité ne représenter qu'un seul caractère.
Je suis d'accord que dans mon énoncé c'est un problème qui figurait pas. Si ça avait été effectivement que des comparaisons à l'identique ça aurait suffit (y'aurait juste eu des trucs un peu moche en cas d'affichage à cause des caractères étendus). Mais il s'est avéré qu'au final j'ai utilisé un algo de stemming sur certains mots et c'est bien que je garde la liberté de pouvoir faire des opérations sur texte, et non seulement sur byte.

Citation:

---

Envoyé par Alp

Bah il paraît qu'il y a un boost.unicode qui est déjà bien avancé

---

Juste mais sauf erreur, les librairies de boost qui concernent l'unicode utilisent des wchar_t. Donc des wstring, donc sous linux c'est vraiment gros. C'est ça qui m'inquiète.

Je suis vraiment sidéré qu'en 2009 bien tassée ça reste encore si difficile d'utiliser Unicode en C++...
Je ne suis pas expert en la matière mais Unicode c'est une norme qui a priori parait tout à fait remarquable avec son 'unification' des codes de toutes les langues et de tous les systèmes de symboles graphiques, qu'est-ce qu'on attend pour s'y mettre à fond et sans regrets...?

Unicode, c'est déjà pas vraiment une norme, mais plusieurs. Alors laquelle ? UTF-8 ? UTF-16 ? UCS-2 ? UCS-4 ?

Ensuite, c'est une norme qui est peut-être très bien en terme d'exaustivité, mais qui est assez coûteuse. Qu'on puisse toujours utiliser des alternatives me semble un bon point.

Enfin, en C++, des bibliothèques existent pour gérer ça. Je crois que des choses sont prévues dans la prochaine version du langage, mais je n'ai pas trop suivi cette partie.

Je suis désolé Unicode est une norme qui possède trois implémentations (trois formes d'encodage) UTF-8, UTF-16 et UTF-32.

Cela dit vu l'âge du C++ je trouve très surprenant que ces bibliothèques dont tu parles soient encore à venir... Je me demande si cela ne vient pas d'un certain manque de préoccupation pour le traitement des langues humaines dans leur diversité... Mais enfin bon nous sommes quelque peu hors sujet ici, je le confesse

Citation:

---

Avec des QString je peux faire toutes les manipulations de texte (tokenization, regex) de façon sûre, tandis qu'avec un std::string, je suppose que la plupart des API ne tiendront pas du tout compte du fait que plusieurs chars peuvent en réalité ne représenter qu'un seul caractère.

---

Ça dépend vachement des manipulations en question en fait. La plupart vont simplement traiter les unités de 16 bits comme des caractères.

Citation:

---

Juste mais sauf erreur, les librairies de boost qui concernent l'unicode utilisent des wchar_t. Donc des wstring, donc sous linux c'est vraiment gros. C'est ça qui m'inquiète.

---

En fait, je suis l'auteur de Boost.Unicode, et Alp me faisait de la pub.
http://blogloufoque.free.fr/unicode/doc/html/

Unicode est bien un standard. UTF-8, UTF-16 et UTF-32 ne sont que des encodages définis au sein de ce standard; il contient beaucoup d'autres choses.

Citation:

---

Envoyé par loufoque

En fait, je suis l'auteur de Boost.Unicode, et Alp me faisait de la pub.
http://blogloufoque.free.fr/unicode/doc/html/

---

Impressionnant. :ccool:
Je ne pensais pas qu'on avait des contributeurs sur ce forum.

Sinon pour ce qui est de l'unicode en c++, parmi les obstacles il y a peut être le fait que ça n'a jamais été le langage de choix pour faire des interfaces graphiques (enfin j'ai pas l'impression même si QT me surprend en bien) et des applications de gestion.
Aussi, le type char n'a pas un typage très fort contrairement à d'autres langages ou il existe des types byte et char séparés. Je pense que ça soude assez solidement la conception 1 char = 1 byte.

@_skip
Qt != QT8O

Citation:

---

Envoyé par _skip

Aussi, le type char n'a pas un typage très fort contrairement à d'autres langages ou il existe des types byte et char séparés. Je pense que ça soude assez solidement la conception 1 char = 1 byte.

---

Il ne me viendrait pas à l'idée d'utiliser un char (et encore moins un wchar_t) pour stocker un petit entier, tout comme il me me viendrait pas à l'idée d'utiliser un signed char ou un unsigned char pour y mettre un caractère.

Citation:

---

tout comme il me me viendrait pas à l'idée d'utiliser un signed char ou un unsigned char pour y mettre un caractère.

---

Non? C'est pourtant pas juste un héritage du C il me semble...

Citation:

---

Envoyé par _skip

Non? C'est pourtant pas juste un héritage du C il me semble...

---

Ce que voulais probablement dire JolyLoic c'est qu'on n'utilises pas un signed char ou un unsigned char pour stocker un caractère mais bel et bien un char (ou un wchar_t).

Et ça me contredit ?
J'ai du mal à croire que la conception char = byte = caractère existe que dans ma tête :aie:. Pour wchar_t, ok je discute pas mais sinon...

Les fonctions de Qt censées manipuler des octets bruts (et pas du texte) utilisent des tableaux de char et non pas unsigned char. Donc soit je mélange tout, soit char porte quand même à confusion par sa polyvalence.

C'est à mon sens une erreur de Qt d'avoir fait ainsi. Typiquement, quand je fais des entrées/sorties en binaire, j'utilise toujours des unsigned char. Ne serait-ce qu'a cause des surprises que le signe peut causer lorsque je je converti ces valeurs dans d'autres types.