Donc, je travaille sur un projet Plain-C (ANSI 9899: 1999) et j'essaie de déterminer où commencer re: Unicode, UTF-8 et tout ce jazz.
Plus précisément, c'est un projet d'interpréteur de langue et j'ai deux endroits principaux où je devrai gérer Unicode: lire dans des fichiers sources (la langue prend en charge les identificateurs unicode et tels), ainsi que dans les objets «chaîne».
Je suis familier avec toutes les bases évidentes sur Unicode, UTF-7 / 8/16 / 32 & UCS-2/4, ainsi de suite et ainsi de suite ... Je cherche principalement des informations utiles, spécifiques au C (que est, s'il vous plaît non C ++ ou C #, qui est tout ce qui a été documenté ici sur des ressources aussi auparavant) quant à mes «prochaines étapes» pour mettre en œuvre des trucs de l'unicode ... en c.
Tous les liens, mantres, articles Wikipedia, exemple de code, sont tous extrêmement les bienvenus. J'essaierai également de conserver une liste de ces ressources ici dans la question initiale, pour que quiconque se passe à travers elle plus tard.
man 3 iconv (ainsi que iconv_open et iconvctl )
- Composants internationaux pour Unicode (via Geoff Reedy )
-
libbasekit , qui semble inclure la lumière Outils de manutention UNICODE
- Glib a des fonctions Unicode
- une base Détecteur UTF-8 fonction , par Christoph
3 Réponses :
Composants internationaux pour UNICODE fournit une bibliothèque portative C pour la manipulation de l'UNICODE. Voici leur hauteur d'ascenseur pour l'ICU4C:
Les langues C et C ++ et de nombreux environnements de système d'exploitation ne fournissent pas de support complet pour les services de manutention de texte Unicode et conformes aux normes. Même si certaines plates-formes fournissent de bons services de traitement de texte Unicode, le code d'application portable ne peut pas en utiliser. Les bibliothèques de l'ICU4C remplissent dans cet espace. L'ICU4C fournit une base ouverte, flexible et portable pour les applications à utiliser pour leurs exigences de mondialisation de logiciels. L'ICU4C suit étroitement les normes de l'industrie, y compris Unicode et CLDR (référentiel de données locales communes).
J'ai entendu parler de cela (je pense que Joel l'a mentionné dans le lien que j'ai ajouté au premier post) ... J'ai peur de toucher quoi que ce soit d'IBM, cependant, ils semblent avoir tendance aux logiciels monolithiques. Je suis plus à la recherche de STDLIB-C Stuff, astuces, et tels que les bibliothèques ... J'essaie de garder mes dépendances très clairement pour ce projet. Cela dit, je les ajouterai au poste d'origine, ils peuvent être utiles aux autres. Quelle est la perte l'ICU? Peut-être que s'ils sont vraiment légers / simples, cela vaut mon temps ...
L'ICU est la norme Industrie non Microsoft dans le traitement Unicode - aucune nécessité de pécher. Bien que la courbe d'apprentissage soit escarpée. BTW - Si vous êtes intéressé uniquement à transporter et à représenter unicode correctement que vous n'avez pas besoin de l'ICU. L'ICU consiste à travailler avec Unicode.
Spécifiquement, je pense que dans ce moment donné, le minimum que je dois faire est de lire dans (au moins) les fichiers UTF-8 / ASCII et de les convertir en une représentation interne, tokenized, UTF-32 'String'. Puis-je facilement (-ish) faire cela sans ICU ou avec quelque chose de briquet?
@elliottcable: Si c'est tout ce que vous voulez faire, vous n'avez besoin que d'un décodeur UTF-8, qui peut être facilement écrit à partir de zéro; J'ai déjà un validateur ( Stackoverflow.com/Questtions/1031645/... ) et un encodeur ( Oui, je suppose autant. La question se tient, cependant; Je cherche toujours des ressources unicodes plus utiles, pas seulement pour moi-même, mais pour d'autres. (-:
L'ICU est utilisé et développé par un certain nombre d'organisations, y compris IBM. Vous pouvez le recondiquer pour simplement inclure les fonctionnalités que vous souhaitez. Beaucoup de "poids" a à voir avec plus de 150 langues, plus de 260 sublocales, des centaines de codépages, etc.
Je pense que l'une des questions intéressantes est - qu'est-ce que votre format interne canonique pour les cordes? Les 2 choix évidents (pour moi au moins) sont
a) UTF8 dans la vanille c Strings b) UTF16 dans les matrices courtes non signées
Dans les projets précédents, j'ai toujours choisi UF-8. Pourquoi ; parce que c'est le chemin du moindre résistance dans le monde C. Tout ce que vous êtes interface avec (stdio, string.h, etc.) fonctionnera bien.
Suivant vient - Quel format de fichier. Le problème ici est que c'est visible pour vos utilisateurs (sauf si vous fournissez le seul éditeur de votre langue). Ici, je suppose que vous devez prendre ce qu'ils vous donnent et essaie de deviner par un coup d'œil (aide des marques d'ordre d'octets)
GLIB a un Fonctions Unicode et est une bibliothèque assez légère. Ce n'est pas près du même niveau de fonctionnalité que l'ICU fournit, mais cela pourrait être suffisant pour certaines applications. Les autres caractéristiques de la GLIB sont bonnes à avoir pour les programmes C portables C.
GTK + est construit sur la glib. Glib fournit aux constructions de langues algorithmiques fondamentales dupliquées couramment dans les applications. Cette bibliothèque dispose de fonctionnalités telles que (cette liste n'est pas une liste complète):
- Système d'objet et de type
- boucle principale
- Chargement dynamique de modules (c'est-à-dire plug-ins)
- Support thread
- support de minuterie
- Allocator mémoire
- files filetées (synchrones et asynchrones)
- Listes (liées individuellement, doublement liées, double terminée)
- Tables de hachage
- Tableaux
- arbres (n-ary et binaire équilibré)
- String Utilities et manipulation Chart
- Scanner lexical et analyseur XML
- base64 (codage et décodage)
+1 pour iconv, où qu'il soit disponible. sur Windows ICU pourrait être une meilleure option