Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Unicode est-il vraiment un probleme ?
Une question que je me suis posé en lisant boost:filesystem
qui n'utilise pas unicode pour les noms de fichier et meme abandonné par les Library Working Group members.
A votre avis Unicode est-il vraiment necessaire pour la gestion des fichiers sur Windows par exemple ?
Qelqu'un a-t-il deja eu des problemes de ce genre ?
Merci
Franchement, pas trop. La plupart des fonctions d'accès aux fichier de Win32 ont une version Unicode et une version "normale" (généralement, le charset utilisé est Windows-1252).
Aussi, il n'y a pas trop de problème, à moins de confondre des accents entre "ANSI" et "OEM" (Windows-1252 / IBM-850 (console)) ou d'utiliser des caractères absents du Windows-1252 (comme des caractères japonais).
Pour le problème des accents, un exemple typique est l'archiveur IZArc, qui n'aime pas trop la commande "Extract here" dans un dossier dont le chemin comprend des accents (À commencer, hélas, par C:\Documents and Settings\Propriétaire qui devient C:\Documents and Settings\PropriÚtaire...)
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
J'ai l'impression qu'unicode est present maintenant a peu pres partout (par ex fichier xml / html ...), et qu'il n'y a pas de solution concrete disponible en C++, pourquoi finalement boost ne propose-t-il pas une classe String qui gere tout ca et est unicode en interne ?
aussi de plus en plus de fichier sont au format utf-8, alors comment faire avec les iostream ? le type wchar_t est vraiment deconseillé partout.
que faire ... ?
a priori windows est quand meme largement en train de pousser vers l'unicode ... Java et C# ne sont qu'utf-8 !
Euh... C# est en UTF-16, tout comme le reste de Windows (et java aussi, il me semble).
Et n'oublie pas que sous Windows, wchar_t == UTF-16.
Par contre, les classes de flux du framework .Net donnent tout ce qu'il faut pour écrire dans tous les modes... À commencer par l'UTF-8 et l'UTF-16.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
heu ... bah autant pour moi ... mais c'est quand meme tres genant que C++ n'ait rien pour gerer l'unicodeEnvoyé par Médinoc
Ben... le C++ standard a les wchar_t et on peut faire des string avec.
Par contre, c'est vrai qu'il n'y a rien en standard pour enregistrer en UTF-8...
On n'a droit qu'à du mono-octet ou du wchar_t (souvent UTF-16 ou même UTF-32). D'ailleurs, même avec les streams de texte, on n'enregistre pas en unicode : C'est converti...
Le seul moyen, c'est de convertir en UTF-8 avec des fonctions non-standard (WideCharToMultiByte() sous Windows, je ne sais plus quoi sous unixoïde) et d'écrire ensuite dans le fichier.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Unicode en C++
Vous utilisez quoi en general comme string ?
les std::string ou autres et pourquoi ?
Merci a+
Moi, je n'utilise pas le C++ standard : Je programme en TCHAR sous Windows
(Les TCHAR permettent de choisir, sous Windows, si on fait du char ou du wchar_t, juste en changeant une option dans le projet). En fait, c'est comme si je programmais toujours en wchar_t sous Windows, donc UTF-16...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
mais dans le cas d'applications multiplateformes ?
Où as tu vu passer ça ? J'en était resté à ce que boost::filesystem devait avoir ça dans sa prochaine version, et que la version du working group l'avait aussi....
Oui. L'autre format dont parle certain pour les fonctions de l'API win32, c'est non pas de l'UTF quoi que ce soit, mais un format spécifique windows pour lequel je n'ai pas encore réussi à trouver de convertions sans pertes depuis un std::wstring.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Euh... Tu veux parler de ce qu'on appelle le format "ANSI" (qui n'a jamais été certifié par l'ansi, d'ailleurs) ?
C'est du Windows-1252, et c'est donc normal qu'il n'y ait pas de conversion sans perte depuis unicode... Il n'y en a pas non plus de unicode à ISO-8859-1, après tout.
Il y a aussi quelques codepages muti-byte, notamment pour les langages asiatiques :
http://en.wikipedia.org/wiki/Multi-b...byte_encodings
Et pour finir, les fonctions de conversion de Windows supportent également la conversion UTF-16 --> UTF-8. Et comme je l'ai dit dans mon premier post, la plupart (pas tous, c'est vrai) des noms de fichiers "tiennent" dans de l'ISO-8859-1, et par extension dans du Windows-1252.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Pas forcément vu que c'est une représentation interne.
Tu peux très bien stocker des chaines sous forme de char* ( ce qui n'est pas bien) ou std::string et les réafficher/retranscrire avec conversion unicode...
Unicode c'est principalement pour afficher des textes dans des langues différentes (je pense que tu le sais cela )
Il est vraiment souhaitable de stocker sous forme de std::string dans un fichier et à l'affichage, selon la langue les codes de pages le retransformer....
D'après ce que j'ai compris (je ne me suis pas trop penché sur le problème), la plupart des fonctions windows existent en deux versions : Une version A qui prend des char* encodés en MBCS, et une version W qui prend des wchar_t* encodés en UCS-2.
La version prenant des UCS-2 me plaît bien, car je peux facilement d'après mes tests lire ce format dans un wstream, depuis un prompt utilisateur,... J'ai essayé avec quelques caractères exotiques sans aucun de problèmes.
La version MBCS me gêne plus. Déjà, j'ai bien du mal à trouver une description précise de ce format. Ensuite, quand j'utilise un stream, je ne récupère pas de données dans ce format, mais plutôt dans un format monobyte dépendant de la codepage locales. Par ailleur le format utilisé n'est pas de l'UTF-8 (j'ai fait des tests, les noms de fichier étaient déformés), qui lui est docummenté et pour lequel des conversions sans pertes depuis UCS-2 existent. Une conversion sans perte existe peut-être pour ce format, puisqu'à la base, c'est un peu le but des formats multi-byte, mais je ne l'ai pas trouvée.
Les flux de la STL microsoft ont été étendus par rapport aux flux standard du C++ pour prendre des constructeurs travaillant directement avec des formats wchar_t* codés en UCS-2. J'ai donc une chaîne de travail wstream-wstring qui tourne. J'ai essayé d'introduire boost::filesystem dans cette chaîne, mais sa version actuelle ne me l'a pas permis. Si je me rends compte que la version proposée pour le standard a abandonné l'utilisation de ce codage, je voterai contre.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Tu parles de std::string encodé selon la code de page locale ?
Dans mon cas, on fait des logiciels pour des entreprises multi-nationales, leur servant à aggréger des données de différents pays. Un seul code de page ne pourrait suffire à gérer toutes les données qu'on a à gérer d'un coup. On pourrait certes utiliser un interne un std::string codé en UTF-8 (comme par exemple ce que propose Glib::ustring), mais autant les formats multi-bytes pour le stockage, pourquoi pas, mais pour le traitement...
Honnêtement, je ne vois pas trop d'alternative à l'utilisation de std::wstring dans notre application.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
En fait, la version A prend bien "des char * encodés en MBCS", mais cela dépend de la codepage. Ce sont surtout les codepages asiatiques qui ont du MBCS : Il me semble bien que la Windows-1252 est toujours single-byte (et wikipédia ne semble pas contredire).
(Note: Même sur du MBCS, _tcslen() se résout en strlen(), pour éviter des problèmes d'allocation mémoire).
En tout cas, c'est vrai qu'il n'existe pas de conversion sans perte depuis Unicode vers une codepage MBCS, car les codepages MBCS ne sont pas Unicode : Seul l'UTF-8 l'est.
Donc, Windows 2000 et supérieur ne sont plus UCS-2, mais UTF-16.
En clair, Windows ne supporte l'unicode qu'en mode "Wide", soit UCS-2 ou UTF-16 selon la version. Windows supporte la conversion de UTF-16 à UTF-8 et inversement, mais ne donne aucune fonction pour le traiter (et je n'ai rien vu pour forcer la codepage courante : Je n'ai vu de fonctions que pour la consulter, comme GetACP()).
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Abandoned Designs
operations.hpp
Dietmar Kühl's original dir_it design and implementation supported wide-character file and directory names. It was abandoned after extensive discussions among Library Working Group members failed to identify portable semantics for wide-character names on systems not providing native support. See FAQ.
dans la FAQ:
Why aren't wide-character names supported? Why not std::wstring or even a templated type?
Wide-character names would provide an illusion of portability where portability does not in fact exist. Behavior would be completely different on operating systems (Windows, for example) that support wide-character names, than on systems which don't (POSIX). Providing functionality that appears to provide portability but in fact delivers only implementation-defined behavior is highly undesirable. Programs would not even be portable between library implementations on the same operating system, let alone portable to different operating systems.
The C++ standards committee Library Working Group discussed this in some detail both on the committee's library reflector and at the Spring, 2002, meeting, and feels that (1) names based on types other than char are extremely non-portable, (2) there are no agreed upon semantics for conversion between wide-character and narrow-character names for file systems which do not support wide-character name, and (3) even the committee members most interested in wide-character names are unsure that they are a good idea in the context of a portable library.
[October, 2002 - PJ Plauger has suggested a locale based conversion scheme. Others have indicated support for such an experiment.]
Tu me rassures. Le dernier papier sur le sujet http://www.open-std.org/jtc1/sc22/wg...006/n1934.html date de 2006, et tout y est bien templaté en fonction d'un type de chaîne.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Je suis en train de compiler boost avec mingw
j'ai eu des gros messages me disant que mingw ne fait pas les io wide char
cool !!!
La manière dont MS Windows supporte l'unicode est totalement stupide.
Et je vois mal comment avec leur système ils peuvent prétendre supporter l'UTF-16.
Il n'y a pas de "généralement".Franchement, pas trop. La plupart des fonctions d'accès aux fichier de Win32 ont une version Unicode et une version "normale" (généralement, le charset utilisé est Windows-1252).
Il s'agit du charset local, qui peut être tout et n'importe quoi. Mais qui, sous Windows, est limité. (pas de locale unicode)
Donc Windows a fait deux APIs... Alors que sous linux, on ne fait qu'adapter la locale.
Encore heureux qu'on puisse quand même l'utiliser avec des choses plus sophistiquées que windows-1252
Boost ftw
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager