UTF-8 ou UTF-16 ou UTF-32 ou UCS-2

Ceci n’est pas un problème parce que vous dites:

J’utilise Asp.net, C # et SqlServer 2005

SqlServer utilise UTF-16 à certains endroits (ntext, nvarchar, nchar) et UTF-8 dans quelques emplacements centrés sur XML, sans que vous ne fassiez quelque chose de bizarre.

C # utilise UTF-16 dans toutes ses chaînes, avec des outils pour encoder le traitement des stream et des fichiers qui nous amènent sur …

ASP.NET utilise UTF-8 par défaut et il est difficile de penser à un moment où ce n’est pas un bon choix (même avec les langues asiatiques, la concision textuelle de ces langues s’est combinée au fait que les noms et les symboles ont une signification En HTML, CSS, JavaScript, la plupart des applications XML et autres stream que vous enverrez vont de la plage U + 0000 à U + 007F, l’avantage de UTF-16 sur UTF-8 dans cette plage est moins significatif qu’avec le texte brut de Langues asiatiques).

La conversation entre UTF-16 de SqlServer et C # et UTF-8 qu’ASP.NET fait en lecture et en écriture est faite pour vous avec les parameters par défaut, mais comme il s’agit du bit que vous pouvez facilement modifier, ma réponse est donc serait d’utiliser UTF-8. Vraiment, vous utiliserez un mélange de -8 et -16, mais vous ne le remarquerez pas la plupart du temps (avez-vous remarqué que vous l’avez déjà fait).

SQL Server est un peu moins tolérant, ne serait-ce que parce que beaucoup d’exemples obsolètes ont du texte attendu pour la consommation humaine inséré dans des champs varchar, text ou char. Utilisez-les uniquement pour les codes (par exemple, tous les codes de pays ISO sont dans la plage de char (2), de sorte que nchar (2) ne ferait que gaspiller de l’espace), et seuls nvarchar, ntext et nchar pour les éléments lus et écrits par les utilisateurs.

Donc, je suis maintenant confus quoi utiliser maintenant UTF-8 / UTF-16 / UTF-32 / UCS-2

ce qui est meilleur pour le contenu multilingue et la performance, etc.

UCS-2 est obsolète: il ne peut plus représenter tous les caractères Unicode. UTF-8, UTF-16 et UTF-32 le peuvent tous. Mais pourquoi avoir trois manières différentes d’encoder les mêmes caractères?

Parce que dans le passé, les programmeurs ont fait deux grandes hypothèses sur les chaînes.

1. Ces chaînes sont constituées d’unités de code de 8 bits.
2. Ce 1 caractère = 1 unité de code.

Le problème du texte multilingue (ou même du texte monolingue si cette langue est le chinois, le japonais ou le coréen) est que ces deux hypothèses combinées vous limitent à 256 caractères. Si vous devez représenter plus que cela, vous devez abandonner l’une des hypothèses.

Conserver l’hypothèse n ° 1 et abandonner l’hypothèse n ° 2 vous donne un encodage à largeur variable (ou multi-octets ). Aujourd’hui, l’encodage à largeur variable le plus répandu est UTF-8.

Supprimez l’hypothèse n ° 1 et conservez l’hypothèse n ° 2 pour obtenir un codage à caractères larges . Unicode et UCS-2 ont été conçus à l’origine pour utiliser un codage à largeur fixe de 16 bits, qui autoriserait 65 536 caractères. Les premiers utilisateurs d’Unicode, tels que Sun (pour Java) et Microsoft (pour NT) utilisaient UCS-2.

Cependant, quelques années plus tard, on s’est rendu compte que même si cela ne suffisait pas à tout le monde, la gamme de codes Unicode a été étendue. Maintenant, si vous voulez un encodage à largeur fixe, vous devez utiliser UTF-32.

Mais Sun et Microsoft avaient écrit d’énormes API basées sur des caractères 16 bits et n’étaient pas enthousiastes à l’idée de les réécrire en 32 bits. Heureusement, il restait encore un bloc de 2 048 caractères non affectés sur le “Plan multilingue de base” de 65 536 caractères, pouvant être affectés en tant que “substituts” à utiliser par paires pour représenter des caractères supplémentaires: la forme de codage UTF-16. Malheureusement, UTF-16 ne répond à aucune des deux hypothèses d’origine: non-8 bits et largeur variable.

En résumé:

Utilisez UTF-8 lorsque l’hypothèse d’unités de code à 8 bits est importante.

Ceci s’applique à:

• Les noms de fichiers et les appels de système d’exploitation associés sur les systèmes Unix, qui autorisaient traditionnellement les codages à largeur variable mais ne pouvaient pas accepter '\x00 octets dans des chaînes et ne pouvaient donc pas utiliser UTF-16 ou UTF-32. En fait, UTF-8 a été conçu à l’ origine pour un système d’exploitation basé sur Unix (Plan 9).
• Protocoles de communication conçus autour de stream d’octets.
• Tout ce qui nécessite une compatibilité binary avec US-ASCII mais ne donne pas de traitement spécial aux valeurs d’octet supérieures à 127.

Utilisez UTF-32 lorsque l’hypothèse d’un codage à largeur fixe est importante.

Ceci est utile lorsque vous vous souciez des propriétés des caractères par opposition à leur codage, telles que les équivalents Unicode des fonctions ctypes.h telles que isalpha , isdigit , toupper , etc.

Utilisez UTF-16 lorsqu’aucune hypothèse n’est aussi importante, mais que votre plate-forme utilisait auparavant UCS-2.

Vous écrivez pour Windows ou pour le framework .NET conçu à cet effet? Pour Java? Ensuite, UTF-16 est votre type de chaîne par défaut. pourrait aussi bien l’utiliser.

Puisque vous utilisez C #, toutes vos chaînes seront encodées en UTF-16. ASP.NET encodera les pages HTML réelles dans UTF-8, mais cela se fait en coulisse et vous n’avez pas besoin de vous en soucier.

Considérations de taille

Les trois formes de codage UTF nécessitent différentes quantités de mémoire pour représenter un caractère:

• Les caractères U + 0000 à U + 007F (ASCII) nécessitent 1 octet en UTF-8, 2 octets en UTF-16 ou 4 octets en UTF-32.
• Les caractères U + 0080 à U + 07FF (symboles IPA, grec, cyrillique, arménien, hébreu, arabe, syriaque, thaana, nko) nécessitent 2 octets en UTF-8, 2 octets en UTF-16 ou 4 octets en UTF-32. .
• Les caractères U + 0800 à U + FFFF (le rest du BMP, principalement pour les langues asiatiques) nécessitent 3 octets en UTF-8, 2 octets en UTF-16 ou 4 octets en UTF-32.
• Les caractères U + 10000 à U + 10FFFF nécessitent 4 octets dans les trois formes de codage.

Ainsi, si vous souhaitez économiser de l’espace, utilisez UTF-8 si vos caractères sont principalement en ASCII, ou UTF-16 si vos personnages sont principalement en Asie.

Tout d’abord, oubliez UCS-2: il est obsolète. Il ne contient qu’un sous-ensemble de caractères Unicode. Oubliez aussi le format UTF-32: il est très volumineux et très redondant. Ce n’est pas utile pour la transmission de données.

Dans les pages Web, la plus économique est UTF-8 si la plupart des langues que vous manipulez sont de type occidental (latin, cyrillique, grec, etc.). Mais si la bande passante et les temps de chargement ne sont pas un problème, vous pouvez également utiliser UTF-16. Assurez-vous simplement de toujours savoir dans quel format se trouvent les données lorsque vous manipulez un byte[] . Et n’essayez pas de convertir des jeux de caractères 8 bits obsolètes tels que ISO-8859 ou Windows-1252, car vous risqueriez de perdre des données.

En code C #, vos objects ssortingng seront en interne en UTF-16, et vous ne pouvez rien y faire. Ainsi, vos opérations de chaîne normales (par exemple, Subssortingng() ) ne sont pas affectées par votre choix de format de sortie. On pourrait soutenir que cela rend plus performant le codage au format UTF-16, mais cela ne vaut pas la peine de le transmettre sur Internet, où le coût de la transmission du format UTF-16 plus grand est supérieur au gain de traitement minime.

Dans SQL Server, vous devez utiliser nvarchar(...) .

UTF-8 ou UTF-16 sont deux bons choix. Ils vous donnent tous deux access à la gamme complète de points de code Unicode sans utiliser 4 octets pour chaque caractère.

Votre choix sera influencé par la langue que vous utilisez et la prise en charge de ces formats. Je pense que UTF-8 fonctionne mieux avec ASP.NET, mais cela dépend de ce que vous faites.

UTF-8 est souvent un bon choix dans l’ensemble car il fonctionne bien avec un code qui n’attend que l’ASCII, contrairement à UTF-16. C’est également le moyen le plus efficace de représenter un contenu constitué en grande partie de notre alphabet anglais, tout en permettant le répertoire complet d’Unicode en cas de besoin. Une bonne raison de choisir UTF-16 serait si votre langage / framework l’utilisait nativement, ou si vous utiliseriez principalement des caractères qui ne sont pas en ASCII, tels que les langues asiatiques.

Hélas, je pense que le problème est (comme il le dit au début) qu’il a SQL Server 2005 qui, si je ne me trompe pas, utilise toujours UCS2 en tant que codage pour N-datatypes (NVARCHAR et co)

Il devra peut-être vivre avec la limitation qui amène ou met à niveau une version plus récente de SQL Server. Généralement, ce que vous verrez si vous commencez à vider UTF-16, c’est-à-dire l’unicode standard utilisé dans .NET, est-ce que c’est comme indiqué que certains caractères seront perdus et remplacés par? marques dans les tables de firebase database.

Remarque rapide: en principe, tout peut être représenté dans le jeu de caractères Unicode. UTF-8 est juste un encodage capable de représenter tous les caractères de cet ensemble.

UCS-2 n’est plus vraiment une chose à utiliser. Il ne peut pas contenir de caractères au-delà de U + FFFF.

Laquelle des trois autres dépend du type d’opérations que vous souhaitez effectuer sur le texte. UTF-8 (généralement, pas toujours!) Occupera moins d’espace disque représentant les mêmes données et constitue un sur-ensemble ssortingct d’ASCII. Il est donc possible que le nombre de transcodages nécessaires soit réduit. Cependant, vous ne pouvez pas indexer votre chaîne ni trouver sa longueur en temps constant.

UTF-32 vous permet de trouver la longueur de la chaîne et de l’indexer en temps constant. Ce n’est pas un sur-ensemble d’ASCII comme UTF-8. Vous devez également disposer de 4 octets par sharepoint code, mais l’espace disque est bon marché.