Quel est l’avantage de choisir le codage ASCII sur UTF-8?


91

Tous les caractères ASCII peuvent être codés avec UTF-8 sans augmentation de la mémoire (les deux nécessitent un octet de mémoire).

UTF-8 présente l'avantage supplémentaire de prendre en charge les caractères au-delà des "caractères ASCII". Si tel est le cas, pourquoi choisirons- nous jamais le codage ASCII sur UTF-8?

Existe-t-il un cas d'utilisation lorsque nous choisirons ASCII au lieu de UTF-8?


9
Pour soutenir les choses héritées ...
fretje

9
Je veux dire l'UTF8 est legacily soutient trop ASCII. Ainsi, même si vous devez prendre en charge les éléments existants, UTF8 fonctionnerait parfaitement sans autre changement.
Pacerier

3
Peut-être devez-vous interagir avec un système contenant 8 caractères ASCII sur 7 octets? Les gens ont fait des choses folles pour s’y adapter.
Donal Fellows

4
Appelez-moi cinglé, mais je dirais sécurité et stabilité. Un jeu de caractères sans séquences multi-octets est beaucoup plus difficile à casser. Ne vous méprenez pas, lorsque le support du langage humain est important, ASCII ne le résoudra pas. Mais si vous ne faites que de la programmation de base et que vous pouvez vous glisser dans le langage natal pour lequel le compilateur et le système d'exploitation ont été écrits, pourquoi ajouter de la complexité? @Donaux Fellows. La dernière fois que j'ai vérifié ... ASCII correspond à 7 octets. (n'importe quoi avec ce petit extra n'est tout simplement pas ASCII et demande des ennuis)
ebyrob

2
@ebyrob Je pense que Donal Fellows signifie que le bit contient 8 octets ASCII en 7 octets, chaque symbole utilisant 7 bits chacun ... 8 * 7 = 56 bits = 7 octets. Cela signifierait une fonction spéciale d'encodage et de décodage, juste pour économiser 1 octet de stockage sur 8.
dodgy_coder

Réponses:


83

Dans certains cas, cela peut accélérer l'accès à des personnages individuels. Imaginez une chaîne str='ABC'encodée en UTF8 et en ASCII (et en supposant que le langage / compilateur / base de données connaisse le codage)

Pour accéder au caractère third ( C) à partir de cette chaîne, utilisez un opérateur d'accès à un tableau, présent dans de nombreux langages de programmation c = str[2].

Maintenant, si la chaîne est encodée en ASCII, tout ce que nous avons à faire est d’extraire le troisième octet de la chaîne.

Si, toutefois, la chaîne de caractères est encodée en UTF-8, nous devons d’abord vérifier si le premier caractère est un caractère à un ou deux octets. Nous devons ensuite effectuer la même vérification sur le deuxième caractère et nous n’aurons alors accès qu’au troisième. La différence de performance sera d'autant plus grande que la chaîne est longue.

Ceci est un problème par exemple dans certains moteurs de base de données, où trouver le début d’une colonne placée "après" un fichier VARCHAR codé en UTF-8, la base de données doit non seulement vérifier le nombre de caractères présents dans le champ VARCHAR, mais également la beaucoup d'octets que chacun utilise.


3
Si la base de données ne stocke pas à la fois le "nombre de caractères" et le "nombre d'octets", je dirais qu'il y a des problèmes ...
Dean Harding

1
TBH Je ne connais aucune base de données qui puisse stocker non plus ...
Mchl

@Mchl: comment imaginez-vous que la base de données sait quand elle a atteint la fin de la chaîne?
kevin cline

1
Habituellement, en atteignant 0x00 ou 0x0000
Mchl

4
@DeanHarding Comment le nombre de caractères vous indique-t-il où commence le deuxième caractère? Ou la base de données doit-elle également contenir un index pour chaque décalage de caractère? Remarque: il ne s’agit pas uniquement de 2 caractères, mais peut en contenir jusqu’à 4 (sauf s’il s’agit de 6) . Stackoverflow.com/questions/9533258/… . (Je pense que ce n'est que l'utf-16 qui a eu les très longues abominations qui pourraient détruire votre système)
ebyrob

7

Si vous n'utilisez que le sous-ensemble US-ASCII (ou ISO 646) de UTF-8, il n'y a alors aucun avantage réel pour l'un ou l'autre; en fait, tout est codé de manière identique.

Si vous allez au-delà du jeu de caractères US-ASCII et utilisez (par exemple) des caractères avec des accents, des trémas, etc., utilisés dans les langues typiques de l'Europe occidentale, il y a une différence - la plupart d'entre eux peuvent encore être codé avec un seul octet dans ISO 8859, mais nécessitera deux octets ou plus lorsqu’il est codé en UTF-8. Bien entendu, il existe également des inconvénients: ISO 8859 exige que vous utilisiez un moyen hors bande pour spécifier le codage utilisé et ne prend en charge qu'un seulde ces langues à la fois. Par exemple, vous pouvez encoder tous les caractères de l’alphabet cyrillique (russe, biélorusse, etc.) en utilisant un seul octet chacun, mais si vous souhaitez / voulez mélanger ceux-ci avec des caractères français ou espagnols (autres que ceux de l’US-ASCII). / ISO 646) vous n’avez pas de chance - vous devez changer complètement les jeux de caractères pour le faire.

ISO 8859 n'est vraiment utile que pour les alphabets européens. Pour prendre en charge la plupart des alphabets utilisés dans la plupart des alphabets chinois, japonais, coréen, arabe, etc., vous devez utiliser un codage complètement différent. Certains d'entre eux (par exemple, Shift JIS pour le japonais) sont une douleur absolue à traiter. S'il y a une chance que vous souhaitiez les prendre en charge, je considère qu'il vaut la peine d'utiliser Unicode au cas où.


5

La norme ANSI peut avoir plusieurs aspects, la plupart étant des jeux de caractères 8 bits (comme la page de code 1252 sous Windows).

Vous pensiez peut-être à ASCII qui est 7 bits et un sous-ensemble approprié de UTF-8. En d'autres termes, tout flux ASCII valide est également un flux UTF-8 valide.

Si vous envisagiez des jeux de caractères de 8 bits, un avantage très important serait que tous les caractères pouvant être représentés sont exactement de 8 bits, où, dans le format UTF-8, ils peuvent atteindre 24 bits.


oui, je parle du jeu ASCII 7 bits. pouvez-vous penser à 1 avantage nous aurons jamais besoin de sauver quelque chose comme ascii au lieu de utf-8? (puisque le 7 bits serait sauvegardé en 8 bits de toute façon, la taille du fichier serait exactement la même)
Pacerier

1
Si vous avez des caractères plus grands que la valeur unicode 127, ils ne peuvent pas être enregistrés en ASCII.

1
@Pacerier: Toute chaîne ASCII est une chaîne UTF-8 , il n'y a donc aucune différence . La routine d'encodage peut être plus rapide en fonction de la représentation sous forme de chaîne de la plate-forme que vous utilisez, bien que je ne m'attende pas à une accélération significative, alors que vous perdez beaucoup en flexibilité.
back2dos

@Thor c'est exactement pourquoi je demande si la sauvegarde en ASCII présente un avantage quelconque
Pacerier le

5
@Pacerier, si vous enregistrez XML en ASCII, vous devez utiliser, par exemple, & # 160; pour un espace insécable. Ceci est plus complet, mais rend vos données plus résistantes aux erreurs de codage ISO-Latin-1 vs UTF-8. C'est ce que nous faisons, car notre plateforme sous-jacente fait beaucoup de magie invisible avec les personnages. Rester en ASCII rend nos données plus robustes.

3

Oui, il existe encore quelques cas d'utilisation de l'ASCII: formats de fichier et protocoles réseau . En particulier, pour les utilisations où:

  • Vous avez des données générées et consommées par des programmes informatiques, jamais présentées aux utilisateurs finaux;
  • Mais il est utile pour les programmeurs de pouvoir lire, pour faciliter le développement et le débogage.

En utilisant ASCII comme codage, vous évitez la complexité du codage sur plusieurs octets tout en conservant au moins une certaine lisibilité.

Quelques exemples:

  • HTTP est un protocole de réseau défini en termes de séquences d'octets, mais il est très utile (du moins pour les programmeurs anglophones) que celles-ci correspondent au codage ASCII de mots tels que "GET", "POST", "Accept-Language" et bientôt.
  • Les types de bloc dans le format d'image PNG se composent de quatre octets, mais c'est utile si vous programmez un encodeur ou un décodeur PNG qui IDATsignifie "données d'image" et PLTE"palette".

Bien sûr, vous devez faire attention à ce que les données ne soient pas réellement présentées aux utilisateurs finaux, car si elles finissent par être visibles (comme cela a été le cas pour les URL), alors les utilisateurs s'attendent à ce que ces données soient dans une langue qu'ils peuvent lire.


Bien dit. C'est un peu ironique que HTTP, le protocole qui transmet le plus d'unicode sur la planète n'ait besoin que de supporter l'ASCII. (En fait, je suppose qu'il en va de même pour TCP et IP, le support binaire, le support ASCII ... c'est tout ce dont vous avez besoin à ce niveau de la pile)
ebyrob

2

Tout d’abord: votre titre utilise / d ANSI, alors que dans le texte vous faites référence à ASCII. Veuillez noter que ANSI n'est pas égal à ASCII. ANSI incorpore le jeu ASCII. Mais le jeu ASCII est limité aux 128 premières valeurs numériques (0 - 127).

Si toutes vos données sont limitées à ASCII (7 bits), peu importe que vous utilisiez UTF-8, ANSI ou ASCII, car ANSI et UTF-8 incorporent l'ensemble complet ASCII. En d'autres termes: les valeurs numériques comprises entre 0 et 127 inclus représentent exactement les mêmes caractères en ASCII, ANSI et UTF-8.

Si vous avez besoin de caractères extérieurs au jeu ASCII, vous devez choisir un codage. Vous pouvez utiliser ANSI, mais vous rencontrez ensuite les problèmes de toutes les différentes pages de code. Créer un fichier sur la machine A et le lire sur la machine B peut produire des textes amusants si ces machines sont configurées pour utiliser des pages de codes différentes, simple parce que la valeur numérique nnn représente différents caractères dans ces pages de codes.

Cet "enfer de la page de code" est la raison pour laquelle la norme Unicode a été définie. UTF-8 n’est qu’un codage unique de cette norme, il en existe beaucoup plus. UTF-16 est le plus utilisé car il s’agit du codage natif pour Windows.

Donc, si vous avez besoin de prendre en charge quelque chose au-delà des 128 caractères du jeu ASCII, mon conseil est de choisir UTF-8 . Ainsi, peu importe et vous n'avez pas à vous soucier de la page de code que vos utilisateurs ont configurée pour leurs systèmes.


si je n'ai pas besoin de prendre en charge plus de 128 caractères, quel est l'avantage de choisir le codage ACSII par rapport au codage UTF8?
Pacerier

En plus de vous limiter à ces 128 caractères? Pas tant. UTF-8 a été spécialement conçu pour prendre en charge les langues ASCII et la plupart des langues occidentales qui "ne" nécessitent que la norme ANSI. Vous constaterez que UTF-8 n'encodera qu'un nombre relativement petit des caractères ANSI supérieurs avec plus d'un octet. Il y a une raison pour laquelle la plupart des pages HTML utilisent UTF-8 par défaut ...
Marjan Venema

1
@ Pacerier, si vous n'avez pas besoin d'encodage supérieur à 127, opter pour ASCII peut s'avérer utile lorsque vous utilisez une API pour encoder / décoder, car UTF nécessite une vérification de bit supplémentaire pour que les octets supplémentaires soient considérés comme le même caractère. ASCII pur qui vient de lire 8 bits sans vérification. Mais je vous recommande uniquement d’utiliser ASCII si vous avez vraiment besoin d’un niveau élevé d’optimisation dans les grands (gros) calculs et si vous savez ce que vous faites dans cette optimisation. Sinon, utilisez simplement UTF-8.
Luciano
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.