Utilisation de la normalisation Unicode pour représenter des chaînes
Les applications peuvent utiliser Unicode pour représenter des chaînes dans plusieurs formulaires. À mesure que l’acceptation Unicode a augmenté, en particulier via Internet, le besoin s’est produit pour éliminer les différences non essentielles dans les chaînes Unicode. Plusieurs représentations pour une combinaison de caractères compliquent les logiciels, par exemple lorsqu’un serveur Web répond à une demande de page ou qu’un éditeur de liens recherche un identificateur particulier dans une bibliothèque.
Attention
Différentes chaînes Unicode peuvent apparaître visuellement identiques, ce qui soulève des préoccupations de sécurité. Pour plus d’informations, consultez Considérations relatives à la sécurité : Fonctionnalités internationales.
En réponse à cette exigence, le Consortium Unicode a défini un processus appelé « normalisation », qui produit une représentation binaire pour l’une des représentations binaires équivalentes d’un caractère. Une fois normalisées, deux chaînes sont équivalentes si et seulement s’ils ont des représentations binaires identiques. La normalisation élimine certaines différences, mais conserve le cas.
Pour utiliser la normalisation Unicode, une application peut appeler les fonctions NormalizeString et IsNormalizedString pour réorganiser les chaînes qui s’enregistrent sur Unicode 4.0 TR#15. La normalisation peut contribuer à améliorer la sécurité en réduisant les représentations de chaînes alternatives qui ont la même signification linguistique. N’oubliez pas, cependant, que la normalisation ne peut pas éliminer entièrement les autres représentations.
Pour obtenir une description détaillée des normes Unicode pour la normalisation, reportez-vous à l’annexe Standard Unicode #15 : Formulaires de normalisation Unicode (UAX #15).
Attention
Étant donné que la normalisation peut modifier la forme d’une chaîne, les mécanismes de sécurité ou les algorithmes de validation de caractères doivent généralement être implémentés après la normalisation. Pour plus d’informations, consultez Considérations relatives à la sécurité : Fonctionnalités internationales.
Fournir plusieurs représentations de la même chaîne
Dans de nombreux cas, Unicode autorise plusieurs représentations de ce qui est, linguistiquement, la même chaîne. Par exemple :
- Capital A avec dieresis (umlaut) peut être représenté sous la forme d’un point de code Unicode unique « Ä » (U+00C4) ou la combinaison du caractère Capital A et de la combinaison du caractère Dieresis (« A » + « ̈ », c’est-à-dire U+0041 U+0308). Les considérations similaires s’appliquent à de nombreux autres caractères avec des marques diacritiques.
- La majuscule A elle-même peut être représentée de la manière habituelle (LETTRE MAJUSCULE LATINE A, U+0041) ou PAR LETTRE MAJUSCULE LATINE A (U+FF21). Des considérations similaires s’appliquent aux autres lettres latines simples (majuscules et minuscules) et aux caractères katakana utilisés dans l’écriture japonaise.
- La chaîne « fi » peut être représentée par les caractères « f » et « i » (U+0066 U+0069) ou par ligature « fi » (U+FB01). Les considérations similaires s’appliquent à de nombreuses autres combinaisons de caractères pour lesquelles Unicode définit des ligatures.
Utiliser les quatre formulaires de normalisation définis
Vos applications peuvent effectuer une normalisation Unicode à l’aide de plusieurs algorithmes, appelés « formulaires de normalisation », qui obéissent à différentes règles. Le Consortium Unicode a défini quatre formes de normalisation : NFC (formulaire C), NFD (formulaire D), NFKC (formulaire KC) et NFKD (formulaire KD). Chaque formulaire élimine certaines différences, mais conserve le cas. Win32 et .NET Framework prennent en charge les quatre formulaires de normalisation.
Le type d’énumération NLS NORM_FORM prend en charge les quatre formulaires de normalisation Unicode standard. Les formulaires C et D fournissent des formulaires canoniques pour les chaînes. Les formes non canoniques KC et KD fournissent une compatibilité supplémentaire et peuvent révéler certaines équivalences sémantiques qui ne sont pas apparentes dans les formulaires C et D. Toutefois, ils le font au détriment d’une certaine perte d’informations, et ne doivent généralement pas être utilisés comme un moyen canonique de stocker des chaînes.
Des deux formes canoniques, la forme C est une forme « composée » et la forme D est une forme « décomposée ». Par exemple, le formulaire C utilise le point de code Unicode unique « Ä » (U+00C4), tandis que le formulaire D utilise (« A » + « ̈ », c’est-à-dire U+0041 U+0308). Ces rendu sont identiques, car « ̈ » (U+0308) est un caractère combinant. Le formulaire D peut utiliser n’importe quel nombre de points de code pour représenter un point de code unique utilisé par le formulaire C.
Si deux chaînes sont identiques sous forme C ou D, elles sont identiques dans l’autre forme. En outre, lorsqu’elles sont correctement rendues, elles s’affichent de façon indistinguique entre elles et à partir de la chaîne non normalisée d’origine.
Une fois normalisées, les chaînes ne peuvent pas être retournées de manière cohérente à leur représentation d’origine. Par exemple, si une chaîne avec un mélange de représentations de caractères composées et décomposées est convertie en forme normalisée, il n’existe aucun moyen de le normaliser dans la chaîne mixte d’origine. Par conséquent, si une application requiert la représentation d’origine de la chaîne, elle doit stocker cette représentation explicitement. Toutefois, la conversion entre les deux formes canoniques est réversible. Une chaîne sous forme C peut être convertie en forme D, puis revenir au formulaire C, et le résultat est identique à la chaîne C de forme d’origine.
Les formulaires KC et KD sont similaires aux formulaires C et D, respectivement, mais ces « formulaires de compatibilité » ont des mappages supplémentaires de caractères compatibles avec la forme de base de chaque caractère. Ces mappages peuvent entraîner la perte de variantes de caractères mineures. Ils combinent certains caractères qui sont visuellement distincts. Par exemple, ils combinent des caractères de largeur totale et de demi-largeur avec la même signification sémantique, ou différentes formes de la même lettre arabe, ou ligature « fi » (U+FB01) et la paire de caractères « fi » (U+0066 U+0069). Ils combinent également certains caractères qui peuvent parfois avoir une signification sémantique différente, comme un chiffre écrit en tant qu’exposant, comme un indice, ou placés dans un cercle. En raison de cette perte d’informations, les formulaires KC et KD ne doivent généralement pas être utilisés comme formes canoniques de chaînes, mais ils sont utiles pour certaines applications.
Le formulaire KC est un formulaire composé et le KD est un formulaire décomposé. L’application peut revenir en arrière entre les formulaires KC et KD, mais il n’existe aucun moyen cohérent d’aller du formulaire KC ou KD à la chaîne d’origine, même si la chaîne d’origine est sous forme C ou D.
Windows, les applications Microsoft et le .NET Framework génèrent généralement des caractères sous forme C à l’aide de méthodes d’entrée normales. Dans la plupart des cas Windows, le formulaire C est le formulaire préféré. Par exemple, les caractères du formulaire C sont générés par Windows entrée clavier. Toutefois, les caractères importés à partir du web et d’autres plateformes peuvent introduire d’autres formulaires de normalisation dans le flux de données.
Les exemples suivants sont dessinés à partir d’UAX #15 et illustrent les différences entre les quatre formes de normalisation.
| Original | Formulaire D | Formulaire C | Notes |
|---|---|---|---|
| « Äffin » | « A\u0308ffin » | « Äffin » | Le ffi_ligature (U+FB03) n’est pas décomposé, car il a un mappage de compatibilité, pas un mappage canonique.${REMOVE}$ |
| « Ä\uFB03n » | « A\u0308\uFB03n » | « Ä\uFB03n » | |
| « Henry IV » | « Henry IV » | « Henry IV » | Roman NUMERAL IV (U+2163) n’est pas décomposé.${REMOVE}$ |
| « Henry \u2163 » | « Henry \u2163 » | « Henry \u2163 » | |
| ga | ka +dix | ga | Les équivalents de compatibilité différents d’un caractère japonais unique n’entraînent pas la même chaîne sous forme C.${REMOVE}$ |
| ka +dix | ka +dix | ga | |
| hw_ka +hw_ten | hw_ka +hw_ten | hw_ka +hw_ten | |
| ka +hw_ten | ka +hw_ten | ka +hw_ten | |
| hw_ka +dix | hw_ka +dix | hw_ka +dix | |
| kaks | k i + a m + ks f | kaks | Les syllabes hangul sont conservées sous la normalisation. |
| Original | Formulaire KD | Formulaire KC | Notes |
|---|---|---|---|
| « Äffin » | « A\u0308ffin » | « Äffin » | Le ffi_ligature (U+FB03) est décomposé sous forme KC, mais pas au format C.${REMOVE}$ |
| « Ä\uFB03n » | « A\u0308ffin » | « Äffin » | |
| « Henry IV » | « Henry IV » | « Henry IV » | Les chaînes obtenues ici sont identiques sous la forme KC.${REMOVE}$ |
| « Henry \u2163 » | « Henry IV » | « Henry IV » | |
| ga | ka +dix | ga | Des équivalents de compatibilité différents d’un caractère japonais unique entraînent la même chaîne sous la forme KC.${REMOVE}$ |
| ka +dix | ka +dix | ga | |
| hw_ka +hw_ten | ka +dix | ga | |
| ka +hw_ten | ka +dix | ga | |
| hw_ka +1 | ka +dix | ga | |
| kaks | k i + a m + ks f | kaks | Les syllabes hangûl sont maintenues sous normalisation. Dans les versions antérieures d’Unicode, les caractères jamo comme ks f avaient des mappages de compatibilité avec k f + s f. Ces mappages ont été supprimés dans Unicode 2.1.9 pour s’assurer que les syllabes hangûl sont conservées. |
Notes
Les deux tableaux ci-dessus ont un droit d’auteur de © 1998-2006 Unicode, Inc. Tous les droits réservés.
Utiliser des formulaires composés pour des Glyphes uniques
De nombreuses séquences de caractères qui correspondent à un glyphe unique n’ont pas de formes composées. Même lorsqu’il est normalisé par formulaire C, un seul glyphe visuel ou élément de texte logique peut être composé de plusieurs points de code Unicode. Par exemple, plusieurs caractères utilisés dans l’écriture lituanien ont des signes diacritiques doubles, car ils n’ont que des formes décomposées. Par exemple, u minuscule avec macro et tilde (« ū̃ », U+016b U+0303, où le premier point de code est un U minuscule avec des macros et le second est un accent aigu combiné).
Exemple
Vous trouverez un exemple pertinent dans NLS : Exemple de normalisation Unicode.
Rubriques connexes