UTF-8 - Définition

Source: Wikipédia sous licence CC-BY-SA 3.0.
La liste des auteurs de cet article est disponible ici.

Inconvénients

Taille variable:
Les caractères sont représentés en UTF-8 par des séquences d’octets de taille variable, ce qui rend certaines opérations sur les chaînes de caractères plus compliquées : le calcul du nombre de caractères ; le positionnement à une distance donnée (exprimée en caractères) dans un fichier texte et en règle générale toute opération nécessitant l’accès au caractère de position N dans une chaîne.
Efficacité:
Pour les langues utilisant beaucoup de caractères extérieurs à US-ASCII, UTF-8 occupe sensiblement plus d’espace.
Par exemple, les idéogrammes courants employés dans les textes de langues asiatiques comme le chinois, le coréen ou le japonais (kanji, par exemple) utilisent 3 octets en UTF-8 contre 2 octets en UTF-16.
De manière générale, les écritures employant beaucoup de caractères de valeur égale ou supérieure à U+0800 occupent plus de mémoire que s’ils étaient codés avec UTF-16 (UTF-32 sera plus efficace uniquement pour les textes utilisant majoritairement des écritures anciennes ou rares codées hors du plan multilingue de base, c’est-à-dire à partir de U+100000, mais il peut aussi s’avérer utile localement dans certains traitements pour simplifier les algorithmes, car les caractères y ont toujours une taille fixe, la conversion des données d’entrée ou de sortie depuis ou vers UTF-8 ou UTF-16 étant triviale).
Séquences invalides:
Par son système de codage, il était éventuellement possible de représenter un code de différentes manières en UTF-8, ce qui pouvait poser un problème de sécurité : un programme mal écrit peut accepter un certain nombre de représentations UTF-8, normalement invalides selon la RFC 3629 et dans les spécifications (maintenant équivalentes entre elles) publiées par l’ISO 10646 et Unicode ; mais ce n’était pas le cas selon la spécification originale, qui permettait de les convertir comme un seul et même caractère.
De fait, un logiciel détectant certaines chaînes de caractères (pour prévenir les injections SQL, par exemple) pouvait échouer dans sa tâche (ce n’est plus le cas si la conformité du codage avec la définition stricte et normalisée d’UTF-8 est vérifiée avant toute chose).
Prenons un exemple tiré d'un cas réel de virus attaquant des serveurs HTTP du Web en 2001 ((en)[2] [3] [4]). Une séquence à détecter pourrait être « /../ » représentée en ASCII (a fortiori en UTF-8) par les octets « 2F 2E 2E 2F » en notation hexadécimale.
Cependant, une manière malformée de coder cette chaîne en UTF-8 serait « 2F C0 AE 2E 2F », appelée aussi en anglais overlong form (forme superlongue). Si le logiciel n’est pas soigneusement écrit pour rejeter cette chaîne, en la mettant par exemple sous forme canonique, une brèche potentielle de sécurité est ouverte. Cette attaque est appelée directory traversal.
Les logiciels acceptant du texte codé en UTF-8 ont été blindés pour rejeter systématiquement ces formes longues car non conformes à la norme : soit le texte entier est rejeté ; mais parfois les séquences invalides sont remplacées par un code de substitution (généralement U+FFFD si l’application accepte et traite ce caractère normalement, parfois un point d’interrogation qui peut poser d’autres problèmes) ; moins souvent, ces séquences interdites sont éliminées silencieusement (ce qui est très peu recommandé).
Page générée en 0.084 seconde(s) - site hébergé chez Contabo
Ce site fait l'objet d'une déclaration à la CNIL sous le numéro de dossier 1037632
A propos - Informations légales
Version anglaise | Version allemande | Version espagnole | Version portugaise