Unicode en C ++11

Question

J'ai fait un peu de lecture autour de la question de l'Unicode, plus précisément, de l'UTF-8 -- (non) support de C++11, et j'espérais que les gourous sur un Débordement de Pile pourrait me rassurer que ma compréhension est correcte, ou un point où j'ai mal compris ou oublié quelque chose, si c'est le cas.

Un court résumé

Tout d'abord, la bonne: vous pouvez définir l'encodage UTF-8, UTF-16 et UCS-4 littéraux dans votre code source. Aussi, l' <locale> - tête contient plusieurs std::codecvt des implémentations qui peut convertir entre tous de l'UTF-8, UTF-16, UCS-4 et de la plate-forme multi-octets codage (bien que l'API semble, pour le moins, à moins qu'une simple). Ces codecvt implémentations peuvent être imbue()'d sur les cours d'eau pour vous permettre de faire la conversion comme vous le lire ou écrire un fichier (ou un autre cours d'eau).

[EDIT: Cubbi points dans les commentaires que j'ai négligé de mentionner l' <codecvt> - tête, qui fournit std::codecvt des implémentations qui ne dépendent pas d'un jeu de paramètres régionaux. Aussi, l' std::wstring_convert et wbuffer_convert fonctions peuvent utiliser ces codecvts pour convertir des chaînes et des tampons directement, en ne s'appuyant pas sur les cours d'eau.]

C++11 comprend également le C99/C11 - <uchar.h> d'en-tête qui contient des fonctions pour convertir les caractères individuels à partir de la plate-forme multi-octets codage (qui peut ou peut ne pas être en UTF-8) et de l'UCS-2 et UCS-4.

Cependant, c'est sur la mesure de l'informatique. Alors bien sûr, vous pouvez stocker du texte UTF-8 en std::string, il n'y a pas moyens que je peux voir à faire quelque chose de vraiment utile. Par exemple, autres que de définir un littéral dans votre code, vous ne pouvez pas valider un tableau d'octets contenant UTF-8 valide, vous ne pouvez pas trouver la longueur (nombre de caractères Unicode, pour une définition de "caractère") de l'UTF-8 contenant de l' std::string, et vous ne pouvez pas effectuer une itération sur un std::string de toute autre manière que celle-octet par octet.

De même, le C++11 pour plus d' std::u16string n'a pas vraiment de support de l'UTF-16, mais seulement les plus âgés de l'UCS-2 -- il n'a pas de support pour les paires de substitution, vous laissant avec seulement le BMP.

Observations

Étant donné que l'UTF-8 est la manière standard de manipuler Unicode sur quasiment toutes les machines Unix dérivé du système (y compris Mac OS X et* Linux) et est devenue le standard de facto sur le web, le manque de soutien en C++ moderne semble être une très grave omission. Même sur Windows, le fait que le nouveau std::u16string n'a pas vraiment de support de l'UTF-16 semble quelque peu regrettable.

_{* Comme indiqué dans les commentaires et a clairement ici, la BSD dérivé de Mac OS utiliser l'UTF-8 alors que le Cacao utilise UTF-16.}

Questions

Si vous avez réussi à lire tout ça, merci! Juste quelques questions rapides, comme c'est le Débordement de Pile, après tout...

• Est l'analyse ci-dessus correcte, ou il y a des autres Unicode installations d'aide je suis absent?

• Le comité des normes a fait un travail fantastique dans les deux dernières années, le déplacement de C++ de l'avant à un rythme rapide. Ils sont tous des gens intelligents et je suppose qu'ils sont bien conscients des inconvénients ci-dessus. Est-il une raison connue que support de l'Unicode reste tellement pauvres en C++?

• À l'avenir, quelqu'un sait de toute proposition visant à remédier à la situation? Une recherche rapide sur isocpp.org ne semble pas révéler quoi que ce soit.

EDIT: Merci à tous pour vos réponses. Je dois avouer que je trouve un peu décourageant -- on dirait que le statu quo n'est pas susceptible de changer dans un avenir proche. Si il y a un consensus parmi les connaisseurs, il semble que la gestion complète de l'Unicode est tout simplement trop difficile, et que toute solution doit ré-écrire la plupart de l'unité de soins intensifs pour être considéré comme utile.

Personnellement, je ne suis pas d'accord avec cela; je pense qu'il est précieux moyen de trouver un terrain. Par exemple, la validation et la normalisation des algorithmes pour l'UTF-8 et UTF-16 sont bien spécifiées par le consortium Unicode, et pourraient être fournis par la bibliothèque standard libre de fonctions de dans, disons, un std::unicode d'espace de noms. Ces seuls seraient d'une grande aide pour le C++ programmes qui ont besoin de faire l'interface avec les bibliothèques attend de saisie Unicode. Mais en fonction de la réponse ci-dessous (teinté, il faut le dire, avec une pointe d'amertume), il semble Chiot proposition justement ce type de fonctionnalité limitée n'a pas été bien reçu.

Answer 1

Est l'analyse ci-dessus correcte

Voyons voir.

vous ne pouvez pas valider un tableau d'octets contenant UTF-8 valide

Incorrect. std::codecvt_utf8<char32_t>::length(start, end, max_lenght) retourne le nombre de bytes dans le tableau.

vous ne pouvez pas trouver la longueur

Partiellement correcte. On peut se convertir à char32_t et de trouver la longueur de la suite. Il n'est pas facile manière de trouver la longueur sans faire la conversion réelle (mais voir ci-dessous). Je dois dire que le besoin de compter les caractères (dans tous les sens), se produit assez rarement.

vous ne pouvez pas effectuer une itération sur un std::string dans toute autre manière que celle de l'octet-par-octet

Incorrect. std::codecvt_utf8<char32_t>::length(start, end, 1) vous donne la possibilité d'effectuer une itération sur UTF-8 "caractères" (code Unicode unités), et bien sûr de déterminer leur nombre (qui n'est pas un "simple" moyen de compter le nombre de caractères, mais c'est une façon).

n'a pas vraiment de support de l'UTF-16

Incorrect. On peut convertir en UTF-16 avec, par exemple, std::codecvt_utf8_utf16<char16_t>. Un résultat de la conversion en UTF-16, UTF-16. Il n'est pas limité à BMP.

Démonstration qui illustre ces points.

Si j'ai raté quelques autres "vous ne pouvez pas", veuillez le signaler et je vous adresse.

Answer 2

Est l'analyse ci-dessus correcte, ou il y a des autres Unicode installations d'aide je suis absent?

Vous êtes également absente de l'échec total de l'UTF-8 littéraux. Ils n'ont pas un type distinct à l'étroit, les chaînes de caractères, qui peuvent avoir une totalement indépendantes (par exemple, les codes) codage. Ainsi, non seulement n'ont-ils pas ajouter de nouvelles installations en C++11, ils ont cassé le peu qu'il y avait, parce que maintenant vous ne pouvez même pas supposer que l' char* est en étroite chaîne de codage pour votre plate-forme, à moins que l'UTF-8 est l'étroite de codage de la chaîne. Ainsi, la nouvelle fonctionnalité est ici ", Nous a complètement cassé char-en fonction des chaînes sur chaque plate-forme où l'UTF-8 n'est pas à l'étroit existant de codage de la chaîne".

Le comité des normes a fait un travail fantastique dans le dernier couple de ans mouvement C++ de l'avant à un rythme rapide. Ils sont tous des gens intelligents et Je suppose qu'ils sont bien conscients des inconvénients ci-dessus. Est-il particulier bien connu de raison que le support de l'Unicode reste tellement pauvres en C++?

Le Comité simplement ne semble pas donner une merde sur Unicode.

En outre, beaucoup de support de l'Unicode des algorithmes ne sont que des algorithmes. Cela signifie que pour offrir une vie décente de l'interface, nous avons besoin de plages. Et nous savons tous que le Comité ne peut pas déterminer ce qu'ils veulent w.r.t. les plages. La nouvelle Iterables chose de Eric Niebler peut avoir un coup de feu.

À l'avenir, quelqu'un sait de toute proposition de rectification de l' situation? Une recherche rapide sur isocpp.org ne semble pas révéler quoi que ce soit.

Il n'y a N3572, à qui j'ai écrit. Mais quand je suis allé à Bristol et l'a présenté, il y avait un certain nombre de problèmes.

Tout d'abord, il s'avère que le Comité n'est pas la peine de commentaires sur la non-Comité-membre-auteur de propositions entre les réunions, résultant en un mois de travail perdues lorsque vous itérer sur un dessin, ils ne veulent pas.

Deuxièmement, il s'avère que c'est voté par quiconque se trouve à errer par le temps. Cela signifie que si votre papier est reportée, vous avez une relativement aléatoire tas de gens qui peuvent ou peuvent ne pas savoir quelque chose au sujet de l'objet. Ou, en fait, rien du tout.

Troisièmement, pour une raison quelconque, ils ne semblent pas vue la situation actuelle comme un problème sérieux. Vous pouvez obtenir des discussion sans fin sur la façon exactement optional<T>s'opérations de comparaison devraient être définis, mais traiter avec la saisie de l'utilisateur? Qui se soucie de qui?

Quatrièmement, chaque papier a besoin d'un champion, effectivement, de présenter et de le maintenir. Étant donné les problèmes précédents, en plus du fait qu'il n'y a aucun moyen que je pouvais me permettre de voyager à d'autres réunions, il n'allait certainement pas être moi, ce ne sera pas moi dans l'avenir, sauf si vous souhaitez faire don de tous mes frais de voyage et de payer un salaire sur le dessus, et personne d'autre ne semblait suffisamment attention à l'effort.