CAN UTF-8 Encodé 5 ou 6 séquences d'octets, permettant à tous les caractères Unicode d'être codés? Je reçois des normes contradictoires. Je dois être capable de soutenir (toutes les citations proviennent de RFC 3629 )
Section 3:
dans UTF-8, caractères de la gamme U + 0000..U + 10FFFF (l'UTF-16
La plage accessible) est codée à l'aide de séquences de 1 à 4 octets. Les
Seul un octet d'une "séquence" d'un a le bit de commande supérieur réglé à 0,
Les 7 bits restants étant utilisés pour coder le numéro de caractère. Dans un
Séquence d'octets N, N> 1, l'octet initial a le n ordre supérieur
bits définis sur 1, suivi d'un bit réglé sur 0. Le ou les bits restants de
cet octet contient des bits du nombre de caractère à
codé. L'octet (s) suivant (s) a tous le bit de commande supérieur réglé à
1 et le bit suivant réglé sur 0, laissant 6 bits dans chacun pour contenir
bits du caractère à encoder.
Donc, tous les caractères possibles ne peuvent pas être codés avec UTF-8? Cela signifie-t-il que je ne peux pas encoder des caractères de différents plans que le BMP?
Section 2:
Les valeurs d'octet C0, C1, F5 à FF n'apparaissent jamais.
Cela signifie que nous ne pouvons pas encoder les valeurs UTF-8 avec 5 ou 6 octets (ou même certaines avec 4 qui ne sont pas dans la plage ci-dessus)?
Section 12:
restreint la gamme de caractères à 0000-10FFFF (l'UTF-16
plage accessible).
En regardant le précédent RFC confirme cela ... ils ont réduit la gamme de caractères.
Section 10:
Un autre problème de sécurité se produit lors de l'encodage de UTF-8: l'ISO / IEC
10646 Description de l'UTF-8 permet de coder les numéros de caractères jusqu'à
U + 7FFFFFFFF, cédant des séquences allant jusqu'à 6 octets. Il y a donc
un risque de débordement de la mémoire tampon si la gamme de numéros de caractères n'est pas
explicitement limité à U + 10FFFF ou si le tampon tampon ne prend pas dans
compte la possibilité de séquences de 5 et 6 octets.
Ces séquences sont donc autorisées par la définition ISO / CEI 10646, mais pas la définition RFC 3629? Lequel devrais-je suivre?
Merci d'avance.
3 Réponses :
Ils ne sont pas Unicode caractères au-delà de 10ffff, le BMP couvre 0000 à FFFF.
utf-8 est bien défini pour 0-10FFFF.
Merci, ça a du sens. Cela signifie-t-il que je n'ai besoin que de vous inquiéter des séquences UTF-8 de plus de 4 octets, avec quelque chose de plus étant une erreur?
@Patrickniedzielski Oui, mais vous devez les traiter comme une erreur ( doit ).
@devio, qu'en est-il des futures versions de Unicode quand ils l'élargissent?
Les avions 3-13 sont toujours non assignés. Je suppose que nous ne devrions pas nous inquiéter;) en.wikipedia.org/wiki/plane_ (Unicode) < / a>
UTF-8 et UTF-16 permettent à tous les caractères Unicode d'être codés. Ce que UTF-8 n'est pas autorisé à faire est d'encoder des moitiés de substitution supérieure et inférieure (utilisations UTF-16) ou des valeurs supérieures à U + 10FFFF, qui ne sont pas légales Unicode.
Notez que le BMP se termine à U + FFFF.
Je dois dire non: les points de code Unicode sont valables pour la plage [0, 0x10ffff] et la carte à 1-4 octets. Donc, si vous avez rencontré un point de code codé de 5 à 6 octets UTF-8, ce n'est pas un point de code valide - il n'y a certainement rien d'attribué là-bas. Je suis un peu déconcerté pourquoi ils sont là dans la norme ISO - je n'ai pas pu trouver une explication.
Il vous fait vous demander, cependant, si peut-être un jour dans le futur, ils élargiraient après U + 10ffff. 0x10ffff permet de plus d'un million de caractères, mais il y a beaucoup de personnages là-bas, et cela dépendrait à quel point il est finalement codé. (Pour la santé de la santé, espérons que non, un million de caractères est beaucoup!) UTF-32 pourrait gérer plus de points de code et comme vous l'avez découvert, UTF-8 pourrait. Ce serait vraiment utf-16 qui n'a pas de chance - plus de paires de substitution seraient nécessaires quelque part dans le spectre des points de code.
L'ISO avait initialement destiné à introduire leur propre codage de caractères 31 bits. UTF-8 a été conçu autour de cette possibilité.
Pour moi, il semble que Unicode essaie de remplir le reste des points de code ... qu'ils ont plus que ce qu'ils savent quoi faire avec. Exemple: il y a un bloc pour les blocs de jeu de Mahjong. Cependant, il y a certainement quelques personnages utiles en dehors du BMP que j'ai besoin de prendre en charge. La plupart d'entre eux sont des ordures, cependant. Cela me fait me demander pourquoi ils n'ont pas accepté les personnages de Klingon un moment.
@ DAN04: tout à fait. C'est pourquoi vous pouvez avoir des caractères abstraits de points de code beaucoup plus élevés que 0x10_ffff, vous ne les utilisez pas pour l'échange UTF. (Parfois, celles-ci s'appellent Supers ou supras .) Par exemple, perl -le 'Imprimer ORMRR CHR (0xFFF_FFFF_FFFF)' Prints 17592186044415 . Cela peut être assez pratique.