Comment interpréter les plages de caractères dans les files charmap?

Le file /usr/share/i18n/charmaps/UTF-8.gz a cette ligne:

 <U3400>..<U343F> /xe3/x90/x80 <CJK Ideograph Extension A> 

La page de carte de charmap(5) indique seulement que cela signifie une plage. Ensuite, j'ai trouvé la spécification , mais elle indique que le nombre dans le nom du personnage est censé être en décimal, pas hexadécimal, et utilise 3 points par opposition à 2 dans la page de manuel. Alors, comment dois-je interpréter les plages de caractères dans les files charmap? Surtout si je vois quelque chose comme

 <U3400>..<U3430> /xe3/x90/x80 <CJK Ideograph Extension A> 

alors la plage est-elle décimale ou hexagonale?

glibc autorise les plages décimales à trois points (comme dans POSIX) et les plages hexadécimales à deux points. Cela ne semble pas être documenté n'importe où, mais nous pouvons le voir dans le code source. Ce n'est pas un comportement portable défini, mais une extension de la glibc et éventuellement d'autres. Si vous écrivez vos propres files, utilisez décimal.


Confirmons que c'est le comportement réel de la glibc.

Lors du traitement d'une plage, glibc utilise :

  if (decimal_ellipsis) while (isdigit (*cp) && cp >= from) --cp; else while (isxdigit (*cp) && cp >= from) { if (!isdigit (*cp) && !isupper (*cp)) lr_error (lr, _("\ hexadecimal range format should use only capital characters")); --cp; } 

isxdigit valide un chiffre hexadécimal et isdigit décimal. Plus tard, il twig la conversion en entier de la sous-string consommée de la même manière et continue comme prévu. Plus tôt, il a déterminé le type d'ellipse en question lors de l'parsing , obtenu à partir du lexer .

Le file UnicodeData.txt UTF-8 est généré mécaniquement à partir du UnicodeData.txt d'unicode.org, créant des plages de 64 points de code avec deux points. Je suppose que cette auto-génération pratique est au less partiellement derrière l'extension, mais je ne sais pas. Les versions antérieures de glibc l'ont également généré, mais en utilisant un programme différent et le même format.

Encore une fois, cela ne semble pas être documenté nulle part, et comme il est généré automatiquement juste à côté de l'endroit où il est utilisé, il pourrait éventuellement changer, mais j'imagine qu'il sera stable.


Si donné quelque chose comme

 <U3400>..<U3430> /xe3/x90/x80 <CJK Ideograph Extension A> 

alors c'est une gamme hexadécimale , parce qu'elle utilise deux points. Avec trois points, ce serait une plage décimale POSIX.

Si vous êtes sur un autre système qui n'a pas cette extension, ce serait juste une erreur de syntaxe. Un file de carte de caractères portable ne doit utiliser que les plages décimales.

La partie entre crochets ( <U3400> ) est le nom UCS du caractère, et les numbers sont en hexadécimal , comme vous pouvez le voir en comparant le nom symbolique <ESC> et son équivalent UCS <U001B> dans la spécification que vous avez liée.

La partie suivante est l'enencoding. Comme vous pouvez le voir sur la spec, il a 3 forms:

\d123123 est décimal,
\x123123 est hexadécimal, et
\123123 est octal.

Donc <U3400> est représenté par la séquence d'octets hexadécimaux e3 90 80 , <U3401> est représenté par la séquence d'octets hexadécimaux e3 90 81 , et ainsi de suite.

Si vous comparez cela avec la description du encoding UTF-8 , vous voyez qu'il correspond: La séquence de 3 octets en tant que bits est

 11100011 10010000 10000000 

et si vous comparez cela avec

 1110xxxx 10yyyyyy 10zzzzzz 

vous voyez que le nombre codé est xxxx yyyy yyzz zzzz , ou 0011 0100 0000 000 , ou 3400 en hexadécimal.