Cette documentation est archivée et n’est pas conservée.

Fonctionnement des codages

En interne, le .NET Framework stocke le texte au format Unicode UTF-16. Un encodeur transforme ces données texte en séquence d'octets. Un décodeur transforme une séquence d'octets en format interne. Un codage décrit les règles qui gouvernent le comportement d'un encodeur ou d'un décodeur. Par exemple, la classe UTF8Encoding décrit les règles qui s'appliquent au codage et au décodage d'une séquence d'octets représentant du texte au format Unicode UTF-8. Le codage et le décodage peuvent également inclure certaines étapes de validation. Par exemple, la classe UnicodeEncoding contrôle tous les substituts afin de vérifier qu'ils constituent des paires de substitution valides. Toutes ces classes héritent de la classe Encoding.

Sélection d'un codage

La classe Encoding est très générale. Les classes prises en charge qui héritent de Encoding permettent aux applications .NET d'utiliser les codages communs qu'elles peuvent rencontrer dans les applications héritées, et les développeurs .NET peuvent implémenter des codages supplémentaires. Toutefois, lorsque vous avez la possibilité de choisir un codage, il est fortement recommandé d'utiliser un codage Unicode, en général UTF8Encoding ou UnicodeEncoding (UTF32Encoding est également pris en charge). En particulier, le UTF8Encoding est généralement préféré au ASCIIEncoding. Si le contenu est ASCII, les deux codages sont identiques, mais le UTF8Encoding peut également représenter tout caractère Unicode, alors que le ASCIIEncoding prend uniquement en charge les valeurs de caractère Unicode comprises entre U+0000 et U+007F. Dans la mesure où le ASCIIEncoding ne fournit pas la détection d'erreurs, le UTF8Encoding est également plus approprié en termes de sécurité.

Le UTF8Encoding a été réglé pour être aussi rapide que possible et doit être plus rapide que tout autre codage. Même pour le contenu qui est entièrement ASCII, les opérations exécutées avec le UTF8Encoding seront plus rapides que les opérations exécutées avec le ASCIIEncoding. Les développeurs doivent utiliser le ASCIIEncoding uniquement pour certaines applications héritées. Toutefois, même dans ce cas, le UTF8Encoding peut encore s'avérer un meilleur choix. Avec les paramètres par défaut, les scénarios suivants peuvent se produire :

  • Si vous avez du contenu interne qui n'est pas strictement ASCII et que vous le codez avec le ASCIIEncoding, chaque caractère non ASCII sera codé comme un point d'interrogation ("?"). Si vous décodez ensuite ces données, les informations seront perdues.

  • Si vous avez du contenu interne qui n'est pas strictement ASCII, et que vous le codez avec le UTF8Encoding, le résultat interprété comme ASCII paraîtra incompréhensible. Toutefois, si vous décodez ensuite ces données, elles seront de nouveau compréhensibles.

Choix d'une stratégie de secours

Lorsqu'une application essaie de coder ou de décoder un caractère, mais qu'il n'existe aucun mappage, vous devez implémenter une stratégie de secours. Une stratégie de secours est un mécanisme de gestion des défaillances. Il existe deux types de stratégies de secours :

  1. Secours d'ajustement

    Lorsque des caractères n'ont pas de correspondance exacte dans le codage/décodage cible, l'application peut décider de les mapper ou non à un caractère semblable.

  2. Secours de chaîne de remplacement

    S'il n'existe aucun caractère semblable approprié, l'application peut spécifier l'élément à insérer dans la chaîne pour marquer l'omission.

Par exemple, une application peut appeler GetEncoding(1252, 0, 0) (consultez GetEncoding) ; la page de codes 1252 est spécifiée (page de codes Windows pour les langues d'Europe de l'Ouest) et les paramètres encoderFallback et decoderFallback ont une valeur égale à zéro. Le comportement par défaut sera un mappage ajusté pour certains caractères Unicode. Par exemple, la LETTRE MAJUSCULE LATINE CERCLÉE S (U+24C8) sera remplacée par la LETTRE MAJUSCULE LATINE S (U+0053) avant d'être codée ; L'EXPOSANT CINQ (U+2075) sera remplacé par le CHIFFRE CINQ (U+0035). Si vous décodez ensuite la page de codes 1252 au format Unicode, le cercle autour de la lettre sera perdu et 25 deviendra 25. D'autres conversions pourront même être plus radicales : le symbole INFINI Unicode (U+221E) peut être mappé à l'EXPOSANT HUIT (U+0038).

Les stratégies d'ajustement varient pour les différentes pages de codes et ne sont pas documentées en détail. Par exemple, pour certaines pages de codes, les caractères latins à pleine chasse sont mappés aux caractères latins à demi-chasse les plus communs ; pour d'autres, ils ne le sont pas.

Même avec une stratégie d'ajustement agressive, il n'y a pas d'ajustement possible pour certains caractères dans certains codages. Par exemple, un idéogramme chinois n'a aucun mappage raisonnable dans la page de codes 1252. Dans ce cas, une chaîne de remplacement est utilisée. Par défaut, cette chaîne correspond à un simple POINT D'INTERROGATION (U+003F).

Le mappage ajusté est le comportement par défaut de Encoding, qui code les données Unicode en données de page de codes, et des applications héritées comptent sur ce comportement. Toutefois, la plupart des nouvelles applications doivent éviter le comportement ajusté pour des raisons de sécurité. (Par exemple, les applications ne doivent pas appliquer un codage ajusté à un nom de domaine.) Utilisez les alternatives suivantes pour le mappage ajusté :

  • Utilisez uniquement les codages Unicode (UTF8Encoding, UnicodeEncoding et UTF32Encoding) pour éviter les problèmes de secours.

    Remarque AttentionAttention

    Bien que techniquement, le UTF7Encoding soit un codage Unicode, il est moins fiable et sécurisé que les autres codages. Dans certains cas, la modification d'un bit peut radicalement altérer l'interprétation d'une chaîne UTF-7 entière. Dans d'autres cas, des chaînes UTF-7 relativement différentes peuvent coder le même texte. Par conséquent, lorsque vous avez le choix, n'utilisez pas le codage UTF-7. Le codage UTF-8 est préféré au codage UTF-7.

  • Utilisez EncoderExceptionFallback et DecoderExceptionFallback, qui lèvent une exception (EncoderFallbackException et DecoderFallbackException, respectivement) si un caractère ne correspond pas exactement.

  • Utilisez EncoderReplacementFallback et DecoderReplacementFallback pour toujours substituer une chaîne de remplacement si un caractère ne correspond pas exactement. (Il s'agit du comportement par défaut pour ASCIIEncoding). Par défaut, cette chaîne correspond juste à un point d'interrogation, mais des méthodes permettant à une application de choisir une chaîne différente sont fournies. Bien qu'il s'agisse généralement d'un caractère unique, ce n'est pas une obligation. Pour DecoderReplacementFallback, qui est utilisé lors de la transformation du texte en Unicode, un caractère communément utilisé est le CARACTÈRE DE REMPLACEMENT (U+FFFD).

  • Écrivez votre propre EncoderFallback et/ou DecoderFallback, pour implémenter la stratégie que vous préférez. Consultez Application de codage de secours, exemple.

Deux remarques supplémentaires à propos des stratégies de secours du codage (ou décodage) ajustées :

  • L'ajustement est principalement un problème de codage et non de décodage. Très peu de pages de codes contiennent des caractères qui ne peuvent pas être mappés au format Unicode. Ces caractères ne sont pas utilisés fréquemment, ce qui explique pourquoi ils sont omis du format Unicode.

  • Aucun objet nommé pris en charge ne correspond aux secours ajustés et le secours ajusté pour chaque page de codes est distinct. Si vous voulez être en mesure de naviguer entre le secours ajusté et d'autres secours pour un objet Encoding unique, faites une copie de l'objet ajusté d'origine dans une variable avant d'assigner tout autre objet de secours. Vous pouvez ensuite récupérer le secours ajusté en assignant de nouveau cette valeur à System.Text.Encoding.EncoderFallback (ou System.Text.Encoding.DecoderFallback).

Voir aussi

Afficher: