Quel est lavantage de choisir le codage ASCII par rapport à UTF-8?

Tous les caractères en ASCII peuvent être encodés en UTF-8 sans augmentation du stockage (les deux nécessitent un octet de stockage).

UTF-8 a lavantage 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 plutôt que UTF-8?

Y a-t-il un cas d’utilisation où nous choisirons ASCII au lieu de UTF-8?

Commentaires

  • Pour prendre en charge les éléments hérités …
  • je veux dire que lUTF8 est hérité supportant lASCII également. Ainsi, même si vous devez prendre en charge des éléments hérités, UTF8 fonctionnerait très bien, aucune autre modification nécessaire.
  • Peut-être que vous ‘ devez interagir avec un système qui regroupe 8 caractères ASCII sur 7 octets? Les gens faisaient des choses folles pour intégrer les choses.
  • Appelez-moi fou, mais je ‘ d dit sécurité et stabilité. Un jeu de caractères sans séquences multi-octets est beaucoup plus difficile à briser. Ne vous méprenez pas ‘, lorsque la prise en charge du langage humain est importante, lASCII ne sera pas disponible ‘ t le couper. Mais si vous ‘ faites juste un peu de programmation de base et pouvez vous insérer dans la langue native, le compilateur et le fonctionnement g système ont été écrits pour, pourquoi ajouter la complexité? @Donal Fellows. La dernière fois que jai vérifié … ASCII est 7 octets. (tout ce qui contient ce bit supplémentaire nest que ‘ t ASCII et pose des problèmes)
  • @ebyrob Je pense que Donal Fellows signifie que le bit contient 8 symboles ascii en 7 octets , puisque chaque symbole utilise 7 bits chacun … 8 * 7 = 56 bits = 7 octets. Cela signifierait une fonction spéciale dencodage et de décodage, juste pour économiser 1 octet de stockage sur 8.

Réponse

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

Pour accéder au troisième (C) de cette chaîne en utilisant lopérateur daccès au tableau qui est présenté dans de nombreux langages de programmation, vous feriez quelque chose comme c = str[2].

Maintenant , si la chaîne est encodée en ASCII, tout ce que nous devons faire est dextraire le troisième octet de la chaîne.

Si, cependant, la chaîne est encodée en UTF-8, nous devons dabord vérifier si le premier caractère est un caractère à un ou deux octets, alors nous devons effectuer la même vérification sur le deuxième caractère, et alors seulement nous pouvons accéder au troisième caractère. La différence de performances sera dautant plus grande que la chaîne sera longue.

Cest un problème par exemple dans certains moteurs de base de données, où trouver le début dune colonne placée « après » un VARCHAR encodé en UTF-8 , la base de données na pas seulement besoin de vérifier le nombre de caractères dans le champ VARCHAR, mais également le nombre doctets que chacun deux utilise.

Commentaires

  • Si la base de données ne ‘ stocke pas à la fois le  » nombre de caractères  » et le  » nombre doctets « , puis je ‘ dire il ‘ a quelques problèmes …
  • TBH Je ne connais aucune base de données qui stockerait non plus …
  • @Mchl: comment imaginez-vous que la base de données sait quand elle a atteint la fin de la chaîne?
  • Habituellement en atteignant 0x00 ou 0x0000
  • @DeanHarding Comment le nombre de caractères vous indique-t-il où commence le deuxième caractère ? Ou la base de données devrait-elle également contenir un index pour chaque décalage de caractère? Remarque: il ne contient ‘ t que 2 caractères, mais peut contenir jusquà 4 (sauf sil est ‘ 6) stackoverflow.com/questions/9533258/… . (Je pense quil ‘ est le seul utf-16 qui avait les très longues abominations qui pourraient détruire votre système)

Réponse

Si vous « allez utiliser uniquement le sous-ensemble US-ASCII (ou ISO 646) de UTF-8, alors il ny a aucun avantage réel pour lun ou lautre; en fait, tout est codé de la même manière.

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., qui sont utilisés dans les langues d’Europe occidentale, alors il ya une différence – la plupart d’entre elles peuvent encore être codées avec un seul octet en ISO 8859, mais nécessiteront au moins deux octets une fois codées en UTF-8. Il y a aussi, bien sûr, des inconvénients: ISO 8859 nécessite que vous utilisiez des moyens hors bande pour spécifier le codage utilisé, et il ne prend en charge que une de ces langues à la fois. Par exemple, vous pouvez encoder tous les caractères du cyrillique (russe, biélorusse, etc.) en utilisant un seul octet chacun, mais si vous avez besoin / voulez les mélanger avec des caractères français ou espagnols (autres que ceux du sous-ensemble US-ASCII / ISO 646), vous navez quasiment pas de chance – vous devez complètement changer les jeux de caractères pour ce faire.

ISO 8859 nest 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 certains encodages complètement différents. Certains dentre eux (par exemple, Shift JIS pour le japonais) sont une véritable douleur à gérer. Sil y a une chance que vous vouliez les supporter, je considérerais quil vaut la peine dutiliser Unicode juste en cas.

Réponse

ANSI peut être beaucoup de choses, la plupart étant des jeux de caractères 8 bits à cet égard (comme la page de code 1252 sous Windows).

Peut-être pensiez-vous à ASCII qui est 7 bits et un sous-ensemble approprié de UTF-8. Cest à dire. tout flux ASCII valide est également un flux UTF-8 valide.

Si vous pensiez à des jeux de caractères 8 bits, un avantage très important serait que tous les caractères représentables sont exactement 8 bits, où en UTF -8 ils peuvent être jusquà 24 bits.

Commentaires

  • yes i ‘ je parle lensemble ASCII 7 bits. pouvez-vous penser à un avantage dont nous aurons besoin pour enregistrer quelque chose en ascii au lieu de utf-8? (puisque le 7 bits serait de toute façon enregistré au format 8 bits, la taille du fichier serait exactement la même)
  • Si vous avez des caractères plus grands que la valeur unicode 127, ils ne peuvent pas être enregistrés en ASCII.
  • @Pacerier: Toute chaîne ASCII est une chaîne UTF-8 , il ny a donc aucune différence . La routine dencodage pourrait ê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 ‘ t mattendre à une accélération significative, alors que vous avez une perte significative dans la flexibilité.
  • @Thor cest exactement pourquoi je ‘ m demande si lenregistrement en ASCII présente des avantages du tout
  • @Pacerier, si vous enregistrez XML au format ASCII, vous devez utiliser par exemple & # 160; pour un espace incassable. Cest plus remplissant, mais rend vos données plus résistantes aux erreurs dencodage ISO-Latin-1 vs UTF-8. Cest ce que nous faisons car notre plate-forme sous-jacente fait beaucoup de magie invisible avec les personnages. Rester en ASCII rend nos données plus robustes.

Réponse

Oui, il existe encore des cas dutilisation où lASCII est logique: formats de fichiers 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 pour lesquelles elles sont utiles les programmeurs peuvent lire, pour faciliter le développement et le débogage.

En utilisant ASCII comme encodage, vous évitez la complexité de lencodage multi-octets tout en conservant au moins une certaine lisibilité humaine.

Quelques exemples:

  • HTTP est un protocole réseau défini en termes de séquences doctets, mais il « est très utile (au moins pour les programmeurs anglophones) que ceux-ci correspondent au codage ASCII de mots comme » GET « , » POST « , » Accept-Language « et ainsi de suite.
  • Le les types de blocs au format dimage PNG se composent de quatre octets, mais cest pratique si vous « programmez un encodeur ou un décodeur PNG qui IDAT signifie » données dimage « et PLTE signifie » palette « .

Bien sûr, vous devez faites attention à ce que les données ne soient pas présentées aux utilisateurs finaux, car si elles finissent par être visibles (comme cela sest produit dans le cas des URL), alors les utilisateurs sattendront à juste titre à ces données être dans une langue quils peuvent lire.

Commentaires

  • Bien dit. Il ‘ est un peu ironique que HTTP, le protocole qui transmet le plus dUnicode de la planète, nait besoin que de prendre en charge ASCII. (En fait, je suppose quil en va de même pour TCP et IP, le support binaire, le support ASCII … que ‘ est tout ce dont vous avez besoin à ce niveau de la pile)

Réponse

Tout dabord: votre titre utilise / d ANSI, alors que dans le texte vous faites référence à lASCII. Veuillez noter que ANSI nest pas égal à ASCII. ANSI incorpore lensemble 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 intègrent le jeu ASCII complet. En dautres termes: les valeurs numériques de 0 à 127 inclus représentent exactement les mêmes caractères en ASCII, ANSI et UTF-8.

Si vous avez besoin de caractères en dehors du jeu ASCII, vous devrez choisir un encodage. Vous pouvez utiliser ANSI, mais vous rencontrez ensuite les problèmes de toutes les différentes pages de codes.Créer un fichier sur la machine A et le lire sur la machine B peut / produira 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 page de codes » est la raison pour laquelle le standard Unicode a été défini. UTF-8 nest quun codage unique de cette norme, il y en a beaucoup plus. UTF-16 étant le plus utilisé car il sagit de lencodage natif pour Windows.

Donc, si vous avez besoin de prendre en charge quoi que ce soit au-delà des 128 caractères de lensemble ASCII, mon conseil est daller avec UTF-8 . De cette façon, cela na pas dimportance et vous navez pas à vous soucier de la page de code avec laquelle vos utilisateurs ont configuré leurs systèmes.

Commentaires

  • si je nai pas besoin de prendre en charge au-delà de 128 caractères, quel est lavantage de choisir le codage ACSII sur le codage UTF8?
  • En plus de vous limiter à ces 128 caractères? Pas beaucoup. UTF-8 a été spécialement conçu pour prendre en charge lASCII et la plupart des langues occidentales qui  » seulement  » ont besoin de lANSI. Vous constaterez que UTF-8 encodera seulement un nombre relativement petit de caractères ANSI supérieurs avec plus dun octet. Il y a une raison pour laquelle la plupart des pages HTML utilisent UTF-8 par défaut …
  • @Pacerier, si vous navez ‘ pas besoin dun encodage supérieur à 127, choisir ASCII peut valoir la peine lorsque vous utilisez une API pour encoder / décoder, car UTF a besoin dune vérification de bits supplémentaire pour considérer des octets supplémentaires comme le même caractère, cela peut prendre un calcul supplémentaire plutôt que de lASCII pur qui ne fait que lire 8 bits sans vérification. Mais je ne vous recommande dutiliser lASCII que si vous avez vraiment besoin dun haut niveau doptimisation dans les gros (gros gros) calculs et que vous savez ce que vous ‘ faites dans cette optimisation. Sinon, utilisez simplement UTF-8.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *