Je concevons un nouveau CMS mais je veux la concevoir pour correspondre à tous mes besoins futurs comme le contenu multilingue, donc je pensais que Unicode (UTF-8) est la meilleure solution
Mais avec une recherche, j'ai reçu cet article
Alors je suis maintenant confondu ce qu'il faut utiliser maintenant qui est meilleur pour le contenu et la performance multilingues, etc.
Merci d'avance
6 Réponses :
Remarque rapide: essentiellement, tout peut être représenté dans le jeu de caractères unicode . UTF-8 n'est qu'un coding capable de représenter tous les caractères de cet ensemble.
UCS-2 n'est pas vraiment une chose à utiliser. Il ne peut pas tenir des personnages au-delà de U + FFFF.
Lequel des trois restants dépend de quel type d'opérations que vous voulez faire sur le texte. UTF-8 (généralement, pas toujours!) Prendra moins d'espace sur le disque représentant les mêmes données et constitue un superset strict d'ASCII, de sorte qu'il pourrait réduire la quantité de transcodage nécessaire. 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 superset d'ASCII comme UTF-8. Il faut également que vous ayez 4 octets par point de code, mais bon, l'espace disque est bon marché.
Tout d'abord, oubliez UCS-2: il est obsolète. Il ne contient que un sous-ensemble de caractères Unicode. Oubliez l'UTF-32 aussi: il est très grand et très redondant. Il n'est pas utile pour la transmission de données.
Dans les pages Web, le plus économique est UTF-8 si la plupart des langues que vous gérez 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 bien utiliser UTF-16. Assurez-vous simplement que vous savez toujours quel format les données se trouvent lorsque vous manipulez un en code C #, votre dans SQL Server, vous devez utiliser octet [] . Et n'essayez pas de convertir des ensembles de caractères obsolètes de 8 bits tels que ISO-8859 ou Windows-1252, car vous perdrez des données si vous le faites.
String Les objets seront à l'intérieur de l'UTF-16, et il n'y a rien que vous puissiez faire à ce sujet. Donc, vos opérations de chaîne normales (E.G. SUBSTRING () ) ne sont pas affectées par votre choix de format de sortie. On pourrait affirmer que cela le rend plus performant à encoder comme UTF-16, mais cela ne vaut pas la peine si vous allez le transmettre sur Internet, où le coût de la transmission de l'UTF-16 plus grand l'emporte sur le gain de traitement minuscule. < / p>
nvarchar (...) .
Bien que l'obsélète, PowerShell utilise toujours UCS-2 comme codage de sortie standard de codage.
UTF-8 ou UTF-16 sont de bons choix. Ils vous donnent tous deux accès à la gamme complète de points de code Unicode sans utiliser de 4 octets en hausse de 4 octets pour chaque personnage.
Votre choix sera influencé par la langue que vous utilisez et son soutien à ces formats. Je crois que utf-8 joue le mieux avec ASP.NET dans l'ensemble, mais cela dépendra de ce que vous faites.
utf-8 est souvent un bon choix dans l'ensemble, car il joue bien avec le code qui s'attend uniquement à ASCII, tandis que UTF-16 ne le fait pas. C'est également le moyen le plus efficace de représenter le contenu en grande partie constitué de notre alphabet anglais, tout en permettant au répertoire complet de Unicode si nécessaire. Une bonne raison de choisir UTF-16 serait si votre langue / cadre l'utilisait de manière native, ou si vous allez principalement utiliser des caractères qui ne sont pas dans ASCII, tels que des langues asiatiques.
Ceci est un non-problème parce que vous dites:
J'utilise ASP.NET et C # et SQLSERVER 2005
SQLSERVER utilise UTF-16 dans certains endroits (Ntext, Nvarchar, Nchar) et UTF-8 dans quelques endroits centrés sur XML, sans rien faire bizarre.
C # utilise UTF-16 dans toutes ses chaînes, avec des outils pour encoder lorsqu'il s'agit de traiter des flux et des fichiers qui nous apportent sur ...
ASP.NET utilise UTF-8 par défaut et il est difficile de penser à une heure où ce n'est pas un bon choix (même avec des langues asiatiques, la concision textuelle de telles langues combinées au fait que les noms et symboles Avec une signification particulière dans HTML, CSS, JavaScript, la plupart des applications XML et d'autres flux que vous envmerez sont à partir de la plage U + 0000 à U + 007F, permet de tirer parti de UTF-16 sur UTF-8 dans cette plage moins importante qu'avec. texte simple des langues asiatiques).
La conversation entre l'UTF-16 de SQLServer et C # et l'UTF-8 que ASP.NET effectue en lecture et en écriture, est effectuée pour vous avec des paramètres par défaut, mais comme il s'agit du seul bit que vous pouvez changer facilement, Ma réponse serait donc d'utiliser UTF-8. Vraiment, vous utiliserez un mélange de -8 et -16, mais vous ne remarquerez pas la plupart du temps (avez-vous remarqué que vous l'avez déjà fait).
SQL Server est un peu moins de pardonner, si seulement parce que de nombreux exemples obsolètes ont un texte attendu pour la consommation humaine mise dans des champs Varcharton, texte ou Char. Utilisez celles-ci purement pour les codes (par exemple, tous les codes de pays ISO sont dans la gamme de caractères (2), de sorte que Nchar (2) ne gaspillerait que des espaces) et seulement Nvarchars, Ntext et Nchare pour les choses que les personnes plutôt que des machines liraient et écrivent.
+1 - Mais je stockais un code de 2 caractères comme NCHAR (2), car cela évite toutes les conversions de la page de code qui se produiraient pendant toutes les lectures et écrit de et à la table. Il négocie l'heure de l'espace. En général, la règle «toujours unicode tout le temps» m'a bien servi.
Performance-sage, cela dépend des activités des opérations, et pour certaines, c'est mieux dans le temps et l'espace. Ce n'est pas la raison pour laquelle je l'utilise, je l'utilise car la définition de caractère est plus proche que celle de NCHAR dans la plage spécifiée pour ces codes de la norme. J'aime le type de données qui correspond le mieux à la définition (c'est pourquoi je suis toujours grommulant de la façon dont SQLServer oblige le choix entre Ntext OFT-gaspful Ntext vs. parfois tronquant Nvarchar (4000) par rapport aux postgres où si les données n'ont pas de fin. limite que vous appelez simplement le texte, qu'il s'agisse de 2 cartes ou de 2 millions de dollars et que les offres de DB
alors je suis maintenant confondu ce à utiliser maintenant UTF-8 / UTF-16 / UTF-32 / UCS-2
qui est mieux pour multilingue Contenu et 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 Tous peuvent. Mais pourquoi avoir trois façons différentes d'encoder les mêmes personnages?
Parce que dans l'ancien temps, les programmeurs ont fait deux grandes hypothèses sur les chaînes.
- que les chaînes sont composées d'unités de code 8 bits.
- que 1 caractère = 1 unité de code.
Le problème du texte multilingue (ou même pour le texte monolingue si cette langue était chinoise, japonaise ou coréenne) est que ces deux hypothèses combinées vous limitent à 256 caractères. Si vous avez besoin de représenter plus que cela, vous devez laisser tomber l'une des hypothèses.
Garder l'hypothèse n ° 1 et la suppression de l'hypothèse n ° 2 vous donne une
largeur de variable (ou multi-octets multi-octets ) codage . Aujourd'hui, le codage de la largeur variable la plus populaire est UTF-8. déposer une hypothèse n ° 1 et la tenue de l'hypothèse n ° 2 vous donne un codage
de caractère large . Unicode et UCS-2 ont été conçus à l'origine pour utiliser un codage de largeur fixe de 16 bits, ce qui permettrait 65 536 caractères. Les premiers adoptants d'Unicode, tels que Sun (pour Java) et Microsoft (pour NT), UCS-2. Cependant, quelques années plus tard, il a été réalisé que même que ne suffisait pas pour tout le monde, de sorte que la gamme de codes Unicode a été élargie. Maintenant, si vous voulez un codage à largeur fixe, vous devez utiliser UTF-32.
Mais Sun et Microsoft avaient écrit d'énormes API basées sur des personnages de 16 bits et n'étaient pas enthousiastes à propos de les réécrire pendant 32 bits. Heureusement, il y avait toujours un bloc de 2048 caractères non attribués dans le "plan de base multilingue" de 65 536 caractères d'origine, qui pourrait être attribué sous forme de "substituts de substitution" à utiliser par paires pour représenter des caractères supplémentaires: le formulaire de codage UTF-16. Malheureusement, UTF-16 rencontre ni des deux hypothèses d'origine: c'est à la fois une largeur non 8 bits et variable.
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 systèmes d'exploitation connexes sur les systèmes UNIX, qui ont eu une tradition établie pour permettre des codages de largeur variable, mais ne peuvent pas accepter
'\ x00 octets dans les chaînes et ne peuvent donc pas utiliser UTF- 16 ou UTF-32. En fait, UTF-8 était à l'origine conçu pour un système d'exploitation basé sur UNIX (plan 9).- Protocoles de communication conçus autour des flux d'octets.
- tout ce qui nécessite une compatibilité binaire avec US-ASCII mais ne donne aucun traitement spécial aux valeurs d'octets 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, tels que les équivalents Unicode au
CTYPES.H Fonctions telles queIsalpha ,isdigit ,touppper , etc.
Utilisez UTF-16 lorsque aucune hypothèse n'est aussi importante, mais votre plate-forme utilisée pour utiliser UCS-2. Écrivez-vous pour Windows ou pour la framework .NET conçu pour cela? 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 codées dans UTF-16. ASP.NET codera les pages HTML réelles dans UTF-8, mais cela se fait dans les coulisses et vous n'avez pas besoin de vous soucier.
Considérations sur la taille
Les trois formes de codage UTF nécessitent différentes quantités de mémoire pour représenter un caractère:
- Personnages U + 0000 à U + 007F (ASCII) nécessite un octet dans UTF-8, 2 octets dans UTF-16 ou 4 octets dans UTF-32.
- Personnages U + 0080 à U + 07FF (Symboles IPA, Grec, Cyrillique, Arménien, Hébreu, Arabe, Syriaque, Thaana, NKO) Exiger 2 octets dans UTF-8, 2 octets dans UTF-16, ou 4 octets dans UTF-32.
- Personnages U + 0800 à U + FFFF (le reste du BMP, principalement pour les langues asiatiques) nécessite 3 octets dans UTF-8, 2 octets dans UTF-16 ou 4 octets dans UTF-32.
- Personnages U + 10000 à U + 10FFFF nécessite 4 octets sur les trois formes de codage.
Ainsi, si vous souhaitez économiser de l'espace, utilisez UTF-8 si vos personnages sont la plupart du temps ASCII, ou UTF-16 si vos personnages sont principalement asiatiques.
@Siguesigueben: Il existe de nombreux personnages de substitution qui nécessitent 3 octets dans UTF-8.
Votre relevé de .NET à l'aide de UTF-16 est actuellement incorrect, il n'utilise pas UTF-16, un codage de longueur variable, il utilise UCS-2, un codage de longueur fixe. Cela signifie que .NET ne peut pas représenter des caractères au-dessus de la plage U + FFFF, au moins pas avec la fonctionnalité standard.
Hélas Je pense que le problème est (comme il l'indique au début) qu'il a SQL Server 2005, que si je suis correct utilise toujours UCS2, car il est codé pour N-DaTatypes (Nvarparar et CO)
Il pourrait avoir à vivre avec la limitation qui apporte ou met à jour une nouvelle version de SQL Server. Typiquement ce que vous verrez si vous commencez à démarrer le dumping utf-16 I.e. Standard Unicode tel qu'utilisé dans .NET, c'est que, comme indiqué, certains caractères seront perdus et remplacés par? marques dans les tables de base de données.
Voir aussi: Stackoverflow.com/questions/1049947 / ...
Le DOC que vous référencez des États que l'UCS-2 est le prédécesseur de l'UTF-16. En outre, cela ne discute pas de UTF-32. Cela règle deux de vos quatre options. Vous pensiez déjà à UTF-8 et ne donnez aucune raison pour que vous soyez confus et que vous envisagez de l'UTF-16. -1. (Vous avez 11 upvotes, vous pouvez donc gérer ce bowvote :-)