La bonne façon de gérer Unicode avec C ++ en 2018?

Question

J'ai essayé de chercher stackoverflow de trouver une réponse à cela, mais les questions et les réponses que j'ai trouvé sont autour de 10 ans et je n'arrive pas à trouver un consensus sur le sujet en raison de changements et de progrès possibles.

Il existe plusieurs bibliothèques que je sais de l'extérieur de la stl qui sont censés manipuler unicode

• http://userguide.icu-project.org/
• https://github.com/nemtrif/utfcpp
• https://github.com/CaptainCrowbar/unicorn-lib

Il ya quelques caractéristiques de la stl (wstring,codecvt_utf8) qui ont été inclus, mais les gens semblent être ambivalents à l'égard de l'aide parce qu'ils traitent de l'UTF-16 qui ce site: (utf-8 partout) dit ne doit pas être utilisé et beaucoup de gens en ligne semble d'accord avec la prémisse.

La seule chose que je suis à la recherche de la possibilité de faire 4 choses avec une des chaînes unicode-

1. Lire une chaîne de caractères dans la mémoire
2. Recherche de la chaîne regex utilisant unicode ou ascii, concaténer ou faire de remplacement de texte/mise en forme avec avec ascii+unicode des chiffres ou des caractères.
3. Convertir ascii + le numéro unicode format pour les caractères qui ne rentrent pas dans la plage ascii.
4. Écrire une chaîne de caractères sur le disque ou l'envoyer n'importe où.

À partir de ce que je peux dire icu gère cela et plus encore. Ce que je voudrais savoir c'est si il existe un moyen standard de la manipulation de ce sur Linux, Windows et MacOS.

Je vous remercie pour votre temps.

Answer 1

Je vais essayer de jeter quelques idées ici:

• la plupart des programmes C++/programmeurs simplement supposer qu'un texte est presque opaque séquence d'octets. UTF-8 est probablement coupable pour ça, et il n'est pas surprenant que de nombreux commentaires cv à: ne vous inquiétez pas avec Unicode, tout processus codé en UTF-8 cordes
• uniquement des fichiers contient des octets. À un moment, si vous essayez d'en interne processus de véritables points de code Unicode, vous aurez pour sérialiser que d'octets -> ici encore UTF-8 gagne le point

• dès que vous sortez du Plan Multilingue de Base (16 bits points de code), les choses deviennent plus complexes et plus. Les emoji est particulièrement horrible de processus: un emoji peut être suivie par un sélecteur de variante (U+FE0E SÉLECTEUR de VARIANTE-15 (VS15) pour le texte ou U+FE0F SÉLECTEUR de VARIANTE-16 (VS16) pour emoji-style) afin de modifier son style d'affichage, plus ou moins le vieux - i bs ^ qui a été utilisé dans les années 1970 ascii lorsque l'on voulait imprimer î. Ce n'est pas tout, les caractères U+1F3FB à U+1F3FF sont utilisés pour fournir de l'un couleur de la peau pour 102 de l'homme emoji répartis en six blocs: Dingbats, des Émoticônes, des Divers Symboles, Les Symboles et les Pictogrammes, les suppléments à des Symboles et des Pictogrammes, et de Transport et des Symboles de la Carte.

  Cela veut simplement dire que jusqu'à 3 fois de suite des points de code unicode peut représenter qu'un seul glyphe... Donc l'idée qu'un personnage est un char32_t est toujours une approximation

Ma conclusion est qu'Unicode est une chose complexe, et nécessite vraiment un dédié bibliothèque comme unité de soins intensifs. Vous pouvez essayer d'utiliser des outils simples comme les convertisseurs de la bibliothèque standard lorsque vous ne traitent que de l'BMP, mais prise en charge complète est bien au-delà.

---

BTW: même d'autres langages comme Python qui prétendent avoir un natif de l'unicode (qui est à mon humble avis beaucoup mieux que l'actuel C++) après échoue sur une partie:

• l'interface graphique tkinter bibliothèque ne peut pas afficher les points de code en dehors de la BMP - alors que c'est la norme IDLE Python outil
• différents modules ou de la bibliothèque standard sont dédiés à Unicode, en plus du support de la langue (codecs et unicodedata), et d'autres modules sont disponibles dans le Python Package Index aimez la emoji soutien, parce que la bibliothèque standard ne permet pas de répondre à tous les besoins

Donc pour l'Unicode est pauvre depuis plus de 10 ans, et je n'ai pas vraiment espoir que les choses vont aller beaucoup mieux dans les 10 prochaines années...