Discussion:UTF-8

message: Je connais plutôt bien le domaine des jeux de caractères, des divers codages existants et j'ai du mal à comprendre la formulation de l'introduction ... je n'imagine même pas pour un néophyte. Tout est touffu, confus, inutilement compliqué. Le paragraphe sur le "point de code" illustre bien comment on peut expliquer de façon complexe un concept simple. Le "point de code" (code point en anglais) est tout simplement un index numérique, c'est à dire un entier qui sert à repérer un caractère dans la liste (répertoire ou jeux) de caractères d'Unicode. Je vais rédiger une nouvelle version, plus courte, plus simple et probablement plus juste, en renvoyant les détails techniques dans les paragraphes suivants.Baldodo (d) 12 mars 2012 à 16:33 (CET)
thread_title:  Introduction : incompréhensible 

message: Hum, dans inconviennent, ça serait pas plutot "analyseur lexical" à la place de "analyseur syntaxique" ? En effet, c'est l'analyseur lexical qui contient des règles pour ignorer certains passages ... d'ailleur je ne comprend pas pourquoi utf-8 transformer "/../" de 2 façons différentes ...
--81.56.249.22 20 mars 2006 à 09:31 (CET)
thread_title:  Analyseur lexical 

message: Le passage en UTF-8 c'est tous les soirs ?
- C'est plusieurs fois par jour camarade, même le matin  si tu écris des textes en LaTeX avant le repas de midi. Avec latin1 c'est la galère, ton texte est truffé de hiéroglyphes à cause des accents, mais avec utf-8 c'est nickel chrome, zéro défaut.  Utf-8 c'est tout bon! Balaise! Tous les TeXeurs et toutes les TeXeuses attendaient çà depuis la chute de l'empire romain. C'est-y pas beau l'progrès, hein ? Momo--2.2.145.124 (discuter) 8 février 2015 à 20:37 (CET)
replies: text: La longueur de la séquence, déterminé par le nombre de bits à un consécutifs, si j'ai le temps de le revoir il faut modifier cet article il y a des erreurs, le standard a été modifié et ne permet plus que des séquences de 4 octets au plus, il y aussi de trés intérressantes questions concernant l'utilisation d'utf-8 et les problèmes de sécurité phe 29 aoû 2004 à 04:56 (CEST)
thread_title:  Permier octet d'une séquence 

message: Cela peut paraitre trop technique, mais il y a un sujet qui revient fréquemment dans l'encodage UTF-8 c'est le Byte Order Mark (BOM), moins connu sous le terme de "boutianité".
Lorsque l'on parle de utf8 il est nécessaire de distinguer le "UTF-8 avec BOM" du "UTF-8 avec BOM", et la problématique est très fréquemment abordée, voici quelques exemples variés :
* Décrit dans les spécification de la rfc3629 (voir : )
* plateforme microsoft et langage c# 
* plateforme SUN et langage JAVA (angl.)
* Recommandation ORACLE 
* Programmation en C++ et l'UTF8 
* etc..
On constate que c'est une problématique récurrente et transversale à tous les langages et plate-formes.
Il me semble donc que cet aspect, si il ne devait être pas être détaillé, devrait au moins apparaitre dans la description de l'UTF8, et ce d'autant plus que l'article wiki sur l'unicode  l'aborde dans la partie "Mécanisme de sérialisation des caractères".
A mon humble avis, j'inclurait (a minima) la notion avant la partie "avantage - inconvénient", puis ajouterais ensuite dans les inconvénients le fait de devoir distinguer ces 2 sous-types d'utf8 (sous peine de bug).
: Les Byte Order Marks n'étant pas nécessaires à l'UTF-8 ne font pas partie de la définition de l’encoding transform scheme UTF-8. Ils n'apparaissent pas non plus dans l’encoding transform format UTF-8, mais seulement dans les charsets utilisés dans MIME et les standards du Web et des systèmes d'exploitation et applications.
: Il y a des passages entiers très précis dans le standard Unicode (pas dans la norme ISO/CEI 10646) à leur sujet, mentionnant quand ils sont autorisés et quand ils ne doivent pas apparaître.
: Initialement UTF-8 n'avait pas de BOM, mais depuis que la fonction de contrôle de césure du caractère ZWNBSP (U+FEFF) nécessaire à certaines langues (qui toutefois ne l'utilisaient jamais en début de texte) a été réencodée spécifiquement vers un autre caractère (afin que cette fonction puisse être manipulée isolément), le caractère ZWNBSP ne sert plus guère que comme BOM, et un BOM (codé avec ZWNBSP) peut apparaitre de façon optionnelle dans les documents UTF-8, comme aussi dans d'autres codages MIME (UTF-16, UTF-32, CESU-8, BOCU...).
: Il n'y a aucun BOM dans les encoding transform scheme qui ne travaille pas au niveau des octets mais directement au niveau des « unités de code » (distinctes des « points de code ») qui ont une taille indéfinie mais seulement assez grande pour contenir toutes les valeurs scalaires nécessaires à la représentation des points de code. Les BOM ne sont donc pas des caractères (même si des encoding transform formats utilisent un caractère pour le représenter, un caractère qui ne sera donc pas disponible sans précaution prise au niveau supérieur).
: Si un caractère ZWNBSP doit apparaître en tant que tel au début d’un document codé et sérialisé avec un encoding transform format, le seule moyen de le représenter sera de le coder deux fois (le premier sera un BOM, le second sera le caractère lui-même).
: Verdy p (d) 9 décembre 2009 à 12:44 (CET)
thread_title:  Byte Order Mark (BOM) 

message: les deux derniers points de code dans le tableau m'ont l'air incorrectement codé :
le point de code 10FFFF devrait être codé F4 8F BF BF et non F4 BF BF BF .
 mise à jour : j'ai effectué la correction dans l'article après vérification
Baldodo (d) 19 novembre 2010 à 11:14 (CET)
thread_title:  Erreur dans le tableau des codages ? 

message: Je me demande pourquoi on a choisi une façon aussi compliquée de coder des caractères en maintenant à l'identique l'ASCII
En effet, un octet comporte 256 valeurs possibles. Si on maintient les 128 premières valeurs (0-127), alors les 128 autres valeurs (128-255) peuvent servir d'octet de contrôle.
Avec 3 octets seulement au maximum, on peut donc coder plus de 2 millions de caractères :
n= 128 ! les caractères ASCII seuls
 + 128 * 128 ! caractères ASCII précédés d'un octet de contrôle
 + 128 * 128 * 128 ! caractères ASCII précédés de 2 octets de contrôle
 = 2113664 valeurs possibles
Un considérant un octet au hasard, si sa valeur dépasse 127 alors c'est un octet de contrôle : on doit juste examiner l'octet précédent et l'octet suivant pour trouver le code du caractère associé. Si c'est un octet de valeur inférieure à 127, alors on examine juste au plus les deux octets précédents. --Labidibidou (discuter) 27 février 2018 à 12:11 (CET)
thread_title:  Question au sujet du codage des caractères, UTF8 en particulier