Parser UTF-8

[Jean-Marc Desperrier]

Au fait, si quelqu'un ici doit un jour coder un truc qui décode de
l'UTF-8 ...

N'oubliez pas de vous référer au document suivant de Markus Kuhn :
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
qui teste tous les cas limite à bien gérer.

Comme celui-là par exemple d'après un commentaire de Markus Kuhn :
"A malformed UTF-8 sequence can *never* contain an ASCII
byte, because that ASCII byte is always terminating any malformed
sequence that might precede it. Any ASCII character must resynchronize
the decoder and will then be interpreted correctly as an ASCII
character."

[Erwan David]

Post by Jean-Marc Desperrier
Au fait, si quelqu'un ici doit un jour coder un truc qui décode de
l'UTF-8 ...
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
qui teste tous les cas limite à bien gérer.
"A malformed UTF-8 sequence can *never* contain an ASCII
byte, because that ASCII byte is always terminating any malformed
sequence that might precede it. Any ASCII character must resynchronize
the decoder and will then be interpreted correctly as an ASCII
character."

Mouais, ça dépend du contexte. Moi si y'a un caractère ASCII à un
endroit où il ne devrait pas y en avoir c'est retour avec code
d'erreur UTF-8 mal formé et c'est tout.

[Olivier Miakinen]

Post by Erwan David

Post by Jean-Marc Desperrier
"A malformed UTF-8 sequence can *never* contain an ASCII
byte, because that ASCII byte is always terminating any malformed
sequence that might precede it. Any ASCII character must resynchronize
the decoder and will then be interpreted correctly as an ASCII
character."

Mouais, ça dépend du contexte.

Oui.

Post by Erwan David
Moi si y'a un caractère ASCII à un
endroit où il ne devrait pas y en avoir c'est retour avec code
d'erreur UTF-8 mal formé et c'est tout.

Moi aussi, pour un programme qui doit manipuler la chaîne UTF-8 et en
déduire quelque chose de sensé. Mais pour afficher du texte, par exemple
dans un lecteur de courrier, il vaut mieux savoir se resynchroniser et
afficher le plus possible de caractères corrects plutôt que de stopper à
la première erreur.

[Erwan David]

Post by Olivier Miakinen

Post by Erwan David

Post by Jean-Marc Desperrier
"A malformed UTF-8 sequence can *never* contain an ASCII
byte, because that ASCII byte is always terminating any malformed
sequence that might precede it. Any ASCII character must resynchronize
the decoder and will then be interpreted correctly as an ASCII
character."

Mouais, ça dépend du contexte.

Oui.

Post by Erwan David
Moi si y'a un caractère ASCII à un
endroit où il ne devrait pas y en avoir c'est retour avec code
d'erreur UTF-8 mal formé et c'est tout.

Moi aussi, pour un programme qui doit manipuler la chaîne UTF-8 et en
déduire quelque chose de sensé. Mais pour afficher du texte, par exemple
dans un lecteur de courrier, il vaut mieux savoir se resynchroniser et
afficher le plus possible de caractères corrects plutôt que de stopper à
la première erreur.

Oui ça se défend. Notons qu'il n'y a pas que le cas des octets <127.

Pour toute valeur de l'octet il y a des moments dans les décodage où
il ne peut pas être lu (par exemple entre 128 et 191 c'est forcément
une continuation, au dessus de 191 c'est forcément un début de
caractère, la valeur exacte donnant le nombre d'octets de continuation
qui doivent suivre, etc.) Sans compter 0xFF et 0xFE qui, si mes
souvenirs sont bons ne peuvent jamais apparaître.

[Erwan David]

Post by Olivier Miakinen

Post by Erwan David

Post by Jean-Marc Desperrier
"A malformed UTF-8 sequence can *never* contain an ASCII
byte, because that ASCII byte is always terminating any malformed
sequence that might precede it. Any ASCII character must resynchronize
the decoder and will then be interpreted correctly as an ASCII
character."

Mouais, ça dépend du contexte.

Oui.

Post by Erwan David
Moi si y'a un caractère ASCII à un
endroit où il ne devrait pas y en avoir c'est retour avec code
d'erreur UTF-8 mal formé et c'est tout.

Moi aussi, pour un programme qui doit manipuler la chaîne UTF-8 et en
déduire quelque chose de sensé. Mais pour afficher du texte, par exemple
dans un lecteur de courrier, il vaut mieux savoir se resynchroniser et
afficher le plus possible de caractères corrects plutôt que de stopper à
la première erreur.

Oui ça se défend. Notons qu'il n'y a pas que le cas des octets <127.

Pour toute valeur de l'octet il y a des moments dans les décodage où
il ne peut pas être lu (par exemple entre 128 et 191 c'est forcément
une continuation, au dessus de 191 c'est forcément un début de
caractère, la valeur exacte donnant le nombre d'octets de continuation
qui doivent suivre, etc.) Sans compter 0xFF et 0xFE qui, si mes
souvenirs sont bons ne peuvent jamais apparaître.

Donc la reprise doit se faire sur la première séquence d'octet
représenatnt un caractère valide, le cas <127 n'étant qu'un cas
particulier.

[Jean-Marc Desperrier]

Post by Erwan David

Post by Jean-Marc Desperrier
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
qui teste tous les cas limite à bien gérer.
"A malformed UTF-8 sequence can *never* contain an ASCII
byte, because that ASCII byte is always terminating any malformed
sequence that might precede it. Any ASCII character must resynchronize
the decoder and will then be interpreted correctly as an ASCII
character."

Mouais, ça dépend du contexte.

Tu as lu trop rapidement mon message.

Un décodeur UTF-8 fait ça, et n'a pas le choix de faire autre chose,
c'est imposé par la norme.

*Par contre* ce que l'application décide de faire avec ce caractère
ASCII derrière un séquence UTF-8 invalide, et comment elle traite un
caractère là où elle ne s'y attend pas est entièrement son problème, et
elle est libre de le traiter comme elle veut.

Mais le décodeur doit fournir cela à l'application.

[Erwan David]

Post by Jean-Marc Desperrier

Post by Erwan David

Post by Jean-Marc Desperrier
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
qui teste tous les cas limite à bien gérer.
"A malformed UTF-8 sequence can *never* contain an ASCII
byte, because that ASCII byte is always terminating any malformed
sequence that might precede it. Any ASCII character must resynchronize
the decoder and will then be interpreted correctly as an ASCII
character."

Mouais, ça dépend du contexte.

Tu as lu trop rapidement mon message.
Un décodeur UTF-8 fait ça, et n'a pas le choix de faire autre chose,
c'est imposé par la norme.
*Par contre* ce que l'application décide de faire avec ce caractère
ASCII derrière un séquence UTF-8 invalide, et comment elle traite un
caractère là où elle ne s'y attend pas est entièrement son problème,
et elle est libre de le traiter comme elle veut.
Mais le décodeur doit fournir cela à l'application.

et le décodeur fourni *quoi* à la place du truc faux ?

[Olivier Miakinen]

Post by Erwan David
et le décodeur fourni *quoi* à la place du truc faux ?

C'est exactement la question que je me suis posée à la lecture de
l'article de Jean-Marc...

[Jean-Marc Desperrier]

Post by Erwan David

Post by Jean-Marc Desperrier
Un décodeur UTF-8 fait ça, et n'a pas le choix de faire autre chose,
c'est imposé par la norme.

et le décodeur fourni *quoi* à la place du truc faux ?

Un code d'erreur.
La conversion n'est pas forcément possible, et il faut gérer le cas, et
donc avoir la possibilité de tester les codes d'erreur.

Un niveau au dessus, on peut décider qu'on envoit dans tous les cas un
flux de caractère, et décider par quoi on remplace ce qui ne peut être
décodé, mais en faisant cela on fait potentiellement quelquechose de
dangeureux, suivant le contexte. Il vaut mieux le faire à un niveau où
on maitrise le contexte ...