Unicode hell (sous Windows) [fermé]

Aujourd'hui, je me suis réveillé et j'ai senti que quelque chose n'allait pas avec mon code et toutes les bibliothèques que j'ai jamais utilisées, et je pense que j'avais raison... (ou veuillez indiquer où mon raisonnement est faux)

Commençons I décennie ou deux dans le temps, tout allait bien dans le monde. J'ai parlé à mon voisin et il parlait la même langue: tout simplement l'anglais. Pour moi, mon voisin et Windows, il semblait évident de stocker notre chaîne en 8 bits char s parce que tous les caractères que nous avons utilisés pourraient être stockés dans le 2^8=256 combinaisons disponibles.

Puis L'être miraculeux Internet est venu et m'a permis de parler à des amis en Europe (qui n'avaient pas le temps d'apprendre l'anglais). Cela a été difficile avec notre format char, le nombre de caractères utilisés A facilement dépassé 256, donc dans notre vision tout à fait simpliste, nous avons décidé d'utiliser le wchar_t16 bits. quelque chose appelé UCS-2 unicode. Il a 2 ^ 16=65.536 combinaisons disponibles et cela doit être suffisant pour toutes les langues du monde! Convaincus de notre exactitude nous avons même ajouté des fonctions 16 bits de L'API Windows W comme MessageBoxW et CreateWindowW. Nous avons convaincu chaque programmeur de notre religion et découragé l'utilisation des homologues 8 bits maléfiques (MessageBoxA et CreateWindowA) et mappé un appel à MessageBox automatiquement à MessageBoxW en définissant _UNICODE dans nos builds. Par conséquent, nous devrions également utiliser les fonctions wcs au lieu des anciennes fonctions str (par exemple, strlen devrait maintenant être wcslen, ou utiliser le _tcslen automatiquement mappé).

Puis les choses ont mal tourné, il s'est avéré il y avait d'autres personnes dans le monde qui utilisaient des glyphes encore plus étranges (sans offense) que les nôtres: Japonais, Chinois, etc. Il est devenu mauvais parce que par exemple Chinois a plus 70.000 caractères différents. Beaucoup de jurons se sont produits et nous ont laissé un nouveau type d'unicode: UTF-16. Il utilise également un type de données 16 bits, mais certains caractères nécessitent deux valeurs 16 bits (appelées paire de substitution ). Ce qui signifie que nous ne pouvons pas utiliser d'index sur ces chaînes de 16 bits (par exemple, theString[4] peut ne pas renvoyer le 5ème caractère). De patch L'API Windows il a été décidé que toutes les fonctions W devraient maintenant supporter le format UTF-16, c'était une décision facile puisque toutes les anciennes chaînes UCS-2 étaient également des chaînes UTF-16 valides. Cependant, parce que nous sommes des programmeurs courageux, nous utilisons maintenant les fonctions wcs. Malheureusement, ces fonctions ne sont pas au courant de Substitution et sont toujours conformes au format UCS-2...

Entre-temps, dans un grenier sombre, une autre forme plus compacte d'unicode a été développée: UTF-8. Utilisation d'un type de données 8 bits la plupart des langues occidentales peuvent être stockés dans une seule valeur de 8 bits, tout comme dans les vieux jours. Lorsqu'un glyphe plus exotique est stocké, plusieurs valeurs 8 bits sont utilisées, pour la plupart des langues européennes, 2 suffira. Cependant, il peut développer 4 de ces valeurs, créant essentiellement un type de stockage 32 bits. Tout comme C'est FAT brother UTF-16, nous ne pouvons pas utiliser d'index sur ces chaînes. En raison de son format plus compact UTF-8 est maintenant largement utilisé partout sur Internet car il économise de la bande passante.

Bien, vous avez réussi à de longues écriture-up :) Maintenant j'ai quelques questions / points d'intérêt:

1. OK, je suis assez satisfait de L'utilisation de UTF-8 pour le stockage. Quand je lis un fichier (à partir d'un disque ou D'une réponse HTTP), je détecte la signature UTF-8 "xEFxBBxBF" et mets le contenu à travers MultiByteToWideChar ce qui me laisse avec une chaîne UTF-16. Je peux l'utiliser avec les fonctions API W, Pas de problème. Mais maintenant, je veux modifier la chaîne, remplacer certains caractères etc. Les bonnes vieilles fonctions wcs ne sont plus bonnes, quel noyau les fonctions de chaîne sont-elles compatibles UTF-16? Ou y a-t-il une splendide bibliothèque là-bas que je ne connais pas? Edit: il semble que ICU soit une très bonne solution. J'ai également trouvé que les fonctions wcs ne sont pas complètement inutiles, vous pouvez par exemple toujours utiliser wcsstr pour rechercher, il ne fait que Comparer wchar_t s. Le seul problème est la longueur de la chaîne.

2. N'avez-vous pas le sentiment qu'une erreur laide a été faite lorsque nous avons été forcés d'utiliser des fonctions W déficientes en 16 bits. Le problème ne devrait-il pas avoir été reconnu beaucoup plus tôt et laisser toutes les fonctions API originales prendre des chaînes UTF-8 et intégrer des routines de manipulation de chaînes appropriées? Ou est-ce déjà possible et je suis horriblement trompe? Edit: peut-être que c'était une question stupide, le recul est en effet merveilleux, inutile de mettre quelqu'un en bas en ce moment ;)

3. Pour un accès rapide à l'index des caractères, nous devrions stocker des chaînes dans des valeurs 32 bits. Est-ce normal? (Je peux vous entendre penser: et puis nous avons frappé un langage extraterrestre nécessitant plus de combinaisons et le plaisir recommence...) Il semble que l'inconvénient de cette approche est que nous devrions convertir la chaîne en UTF-16 chaque fois que nous faisons des appels D'API Windows. Edit: juste pour citer Alf P. Steinbach un caractère par index est un rêve désespéré , je le vois maintenant. Une chose que j'ai complètement manqué était le diacritiques . Je pense aussi que c'est une bonne chose à traiter dans le système d'exploitation encodage natif (pour Windows UTF-16). Bien que UTF-8 aurait été un meilleur choix, nous sommes coincés avec UTF-16 maintenant, il ne sert à rien de convertir entre votre code et L'API. Comme suggéré ci-dessous, je vais garder une trace des parties dans une chaîne moi-même par des pointeurs au lieu d'un nombre de caractères.

Je pense que vous méritez vous-même une bonne tasse de thé du mal si cette longue question, allez en chercher un avant de répondre;)

Edit: j'accepte le fait que ma question est fermé, ce serait un meilleur ajustement pour un billet de blog, mais là encore je n'écris pas de blog. Je pense que cette chose d'encodage de caractères est essentielle et devrait être le sujet suivant dans n'importe quel Livre de programmation après le simple exemple de hello world! L'affichage ici attire l'attention de nombreux experts, ces gens ne lisent aucun blog aléatoire et j'apprécie fortement leur opinion. Donc merci à tous pour leur contribution.