J'ai besoin de manipuler des tableaux d'octets UTF-8 dans un environnement de bas niveau. Les chaînes seront préfixes-similaires et conservées dans un conteneur qui exploite ceci (une trie) pour préserver cette similitude préfixe autant que possible, je préférerais utiliser un terminateur à la fin de mes réseaux d'octets, plutôt que ( Dites) un préfixe d'octets.
Quel terminateur dois-je utiliser? semble 0xFF est un octet illégal dans toutes les positions de toute chaîne UTF-8, mais peut-être que quelqu'un sait concrètement?
3 Réponses :
0xFF et 0xfe ne peut pas apparaître dans les données légales UTF-8. Aussi les octets 0xf8 - 0xfd apparaîtront dans la version obsolète d'UTF-8 qui permet de passer à six séquences d'octets.
0x00 est légal mais n'apparaîtra nulle part, sauf dans le codage de U + 0000. C'est exactement la même chose que d'autres codages, et le fait qu'il est légal dans tous ces codages ne l'empêchait jamais d'être utilisé comme un terminateur en cordes C. J'irais probablement avec 0x00 .
L'octet 0xFF ne peut pas apparaître dans une séquence UTF-8 valide, ni l'un des 0xfc, 0xfd, 0xfe.
Tous les octets UTF-8 doivent correspondre à l'une des P>
0xxxxxxx - Lower 7 bit. 10xxxxxx - Second and subsequent bytes in a multi-byte sequence. 110xxxxx - First byte of a two-byte sequence. 1110xxxx - First byte of a three-byte sequence. 11110xxx - First byte of a four-byte sequence. 111110xx - First byte of a five-byte sequence. 1111110x - First byte of a six-byte sequence.
Les normes modernes UTF-8 ne permettent pas plus de séquences de 5 octets et de 6 octets, car elles codent des points de code qui ne peuvent pas être représentés dans UTF-16. RFC 3629 limitée la séquence d'octets max à 4 et la norme UNICODE a adopté cette limitation.
@Remy Labeau, je pense que vous êtes confondre UTF-8 avec CESU-8 . "La CESU-8 définit un schéma d'encodage pour UNICODE identique à l'UTF-8, à l'exception de sa représentation de caractères supplémentaires. Dans la CESU-8, les caractères supplémentaires sont représentés sous forme de séquences de six octets résultant de la transformation de chaque unité de code de substitution UTF-16 en Un formulaire huit bits similaire à la transformation UTF-8, mais sans d'abord convertir les paires de substituts d'entrée en une valeur scalaire. " UTF-8 n'a pas changé.
@RemyleBeau, ou faites-vous référence à RFC 3629 Mise à jour "Modifications de RFC 2279: restreint la gamme de caractères à 0000-10ffff (la plage accessible UTF-16) "?
Oui, c'est ce que je parle de. Ni la RFC 3629 ni la norme officielle Unicode n'autorisent les codépoints au-dessus de U + 10FFFF à utiliser avec UTF-8, ce qui signifie que vous ne pouvez jamais avoir une séquence UF-8 valide supérieure à 4 octets.
@ Remylebeau-Teamb, édité pour ajouter une avertissement.
@ Anony-Mousse, il apparaît dans l'UTF-8 bien comme le codage pour NUL. L'UTF-8 de Java est une variante qui utilise le formulaire de 2 octets pour NUL, mais ce n'est pas standard.
@ Antony-Mousse, Non. L'octet 0 peut apparaître dans une chaîne d'octets UTF-8 valide, ne doit donc pas être utilisé comme séparateur hors bande.
@ Anony-Mousse, l'Oper veut pouvoir marquer où se termine une séquence. Qui nécessite un terminateur hors bande. Il n'y a pas de séparateur / terminateur à bande pour UTF-8.
@ Anony-Mousse, essayez d'écrire du code pour trouver correctement la fin d'une séquence d'octets UTF-8 terminée avec NUL. En Python, wind_end ("% s \ x00"% s.encode ("utf-8")) == len (s) pour toutes les chaînes UNICODE s . Lorsque vous comprenez pourquoi cela ne peut pas être fait, vous comprendrez pourquoi il doit être hors bande.
@ Anony-mousse, re "Je ne peux pas voir cette exigence", voir son commentaire "\ 0 est également un codage d'ASCII juridique, ainsi qu'un codage légal UTF-8 d'un point de code. Je voulais quelque chose d'explicitement pas légal."
@ Anony-mousse, pourquoi vous souciez d'importance? Si le problème spécifie "Valide UTF-8", la conception la plus robuste est celle qui n'assume rien au-delà de "UTF-8 valide valide". En supposant que «Valable UTF-8», ainsi que vos hypothèses préférées non déclarées vont conduire à un code fragile.
@ Anony-mousse, exactement. Si ce que vous stockez comprend des valeurs qui ne sont pas valides C chaînes, par ex. "FOO \ 0BAR \ 0" , vous ne recevez pas de conception robuste en supposant que vous stockiez des chaînes C.
@ Antony-mousse, vrai. Et stocker uniquement des séquences de lettres ASCII minuscules et de chiffres est encore moins sujette d'erreur lorsque toute personne pourrait toucher que vos données peuvent être confondues pour coder. Mais aucune des hypothèses n'est justifiée lorsque votre travail consiste à stocker et à comparer les séquences d'octets UTF-8.
Qu'en est-il de l'utilisation de l'un des caractères de contrôle UTF-8?
Vous pouvez choisir un de http://www.utf8-chartable.de/
Pourquoi ne pas utiliser \ 0 ? C'est le plus compatible.
Bien \ 0 est la terminaison de chaîne. Je crois que cela causerait des problèmes.
Pourquoi, c'est exactement ce qu'il veut faire: "Terminator à la fin"
\ 0 est également un codage ASCII légal, et donc un codage légal UTF-8 d'un point de code. Je voulais quelque chose explicitement pas légal .
Pourquoi ne pas utiliser le personnage légal approprié d'utiliser ici?