certains librairies me renvoient un caractere "x{e9}" qui est egal au
caractere "é" si on les compare avec l'operateur "eq". pourtant, si on les
affiche avec "print Dumper $variable", on obtient tantot "x{e9}", et tantot
"é". certaines fonctions reagissent differemment selon le caractere, alors
qu'ils sont pourtant egaux au sens de l'operateur "eq",
certains librairies me renvoient un caractere "x{e9}" qui est egal au
caractere "é" si on les compare avec l'operateur "eq". pourtant, si on les
affiche avec "print Dumper $variable", on obtient tantot "x{e9}", et tantot
"é". certaines fonctions reagissent differemment selon le caractere, alors
qu'ils sont pourtant egaux au sens de l'operateur "eq",
certains librairies me renvoient un caractere "x{e9}" qui est egal au
caractere "é" si on les compare avec l'operateur "eq". pourtant, si on les
affiche avec "print Dumper $variable", on obtient tantot "x{e9}", et tantot
"é". certaines fonctions reagissent differemment selon le caractere, alors
qu'ils sont pourtant egaux au sens de l'operateur "eq",
Ce qu'il faut comprendre, c'est que perl manipule les chaînes sous
deux formats : en encodage natif (à la machine, généralement
iso-8859-1)
A priori, vous ne devriez pas vous préoccuper de l'encodage interne
des chaînes par perl. Si vous avez l'impression que vous devez vous en
préoccuper, dans 99% des cas, c'est que vous n'avez pas vu une erreur
d'encodage ailleurs...
Ce qu'il faut comprendre, c'est que perl manipule les chaînes sous
deux formats : en encodage natif (à la machine, généralement
iso-8859-1)
A priori, vous ne devriez pas vous préoccuper de l'encodage interne
des chaînes par perl. Si vous avez l'impression que vous devez vous en
préoccuper, dans 99% des cas, c'est que vous n'avez pas vu une erreur
d'encodage ailleurs...
Ce qu'il faut comprendre, c'est que perl manipule les chaînes sous
deux formats : en encodage natif (à la machine, généralement
iso-8859-1)
A priori, vous ne devriez pas vous préoccuper de l'encodage interne
des chaînes par perl. Si vous avez l'impression que vous devez vous en
préoccuper, dans 99% des cas, c'est que vous n'avez pas vu une erreur
d'encodage ailleurs...
Le (on) jeudi 11 décembre 2008 17:15, Paul Gaborit a écrit (wrote) :Ce qu'il faut comprendre, c'est que perl manipule les chaînes sous
deux formats : en encodage natif (à la machine, généralement
iso-8859-1)
Peux-tu préciser ce que tu entends par « encodage natif à la machine » ? Je
ne comprends pas bien. En fait, j'avais l'impression qu'il y avait soit «
suite d'octets dont les valeurs <128 sont traitées comme de l'ascii, et le
reste on sait pas » soit « chaîne de vrais caractères, par opposition à
octets, (en utf8) ».
A priori, vous ne devriez pas vous préoccuper de l'encodage interne
des chaînes par perl. Si vous avez l'impression que vous devez vous en
préoccuper, dans 99% des cas, c'est que vous n'avez pas vu une erreur
d'encodage ailleurs...
J'en profite pour poser une question qui me tracassait un peu. J'ai
l'impression que les seules circonstances où on doit faire gaffe à
l'encodage sont :
- l'encodage du script lui-même, par exemple avec "use utf8;" ;
- les entrées-sorties.
En dehors de ça, on se contrefiche pas mal que l'encodage interne de Perl
soit utf8, UTF-8 ou n'importe quelle variante d'Unicode, vu qu'il va
toujours « do the right thing ». Est-ce vrai ?
Le (on) jeudi 11 décembre 2008 17:15, Paul Gaborit a écrit (wrote) :
Ce qu'il faut comprendre, c'est que perl manipule les chaînes sous
deux formats : en encodage natif (à la machine, généralement
iso-8859-1)
Peux-tu préciser ce que tu entends par « encodage natif à la machine » ? Je
ne comprends pas bien. En fait, j'avais l'impression qu'il y avait soit «
suite d'octets dont les valeurs <128 sont traitées comme de l'ascii, et le
reste on sait pas » soit « chaîne de vrais caractères, par opposition à
octets, (en utf8) ».
A priori, vous ne devriez pas vous préoccuper de l'encodage interne
des chaînes par perl. Si vous avez l'impression que vous devez vous en
préoccuper, dans 99% des cas, c'est que vous n'avez pas vu une erreur
d'encodage ailleurs...
J'en profite pour poser une question qui me tracassait un peu. J'ai
l'impression que les seules circonstances où on doit faire gaffe à
l'encodage sont :
- l'encodage du script lui-même, par exemple avec "use utf8;" ;
- les entrées-sorties.
En dehors de ça, on se contrefiche pas mal que l'encodage interne de Perl
soit utf8, UTF-8 ou n'importe quelle variante d'Unicode, vu qu'il va
toujours « do the right thing ». Est-ce vrai ?
Le (on) jeudi 11 décembre 2008 17:15, Paul Gaborit a écrit (wrote) :Ce qu'il faut comprendre, c'est que perl manipule les chaînes sous
deux formats : en encodage natif (à la machine, généralement
iso-8859-1)
Peux-tu préciser ce que tu entends par « encodage natif à la machine » ? Je
ne comprends pas bien. En fait, j'avais l'impression qu'il y avait soit «
suite d'octets dont les valeurs <128 sont traitées comme de l'ascii, et le
reste on sait pas » soit « chaîne de vrais caractères, par opposition à
octets, (en utf8) ».
A priori, vous ne devriez pas vous préoccuper de l'encodage interne
des chaînes par perl. Si vous avez l'impression que vous devez vous en
préoccuper, dans 99% des cas, c'est que vous n'avez pas vu une erreur
d'encodage ailleurs...
J'en profite pour poser une question qui me tracassait un peu. J'ai
l'impression que les seules circonstances où on doit faire gaffe à
l'encodage sont :
- l'encodage du script lui-même, par exemple avec "use utf8;" ;
- les entrées-sorties.
En dehors de ça, on se contrefiche pas mal que l'encodage interne de Perl
soit utf8, UTF-8 ou n'importe quelle variante d'Unicode, vu qu'il va
toujours « do the right thing ». Est-ce vrai ?
Que le flag utf8 soit activé ou non, en interne, la valeur d'un
scalaire de type chaîne est toujours une suite d'octets. Et on peut y
accéder en tant que suite d'octets (via les fonctions qui manipulent
les octets des scalaires). Maintenant pour toutes les fonctions qui
manipulent des chaînes, c'est transparent.
La seule et unique raison pour laquelle on peut/doit faire appel à
"use utf8;" est lorsque le code du script contient des trucs encodés
en utf8.
C'est la situation la plus courante (mais pas obligatoirement la plus
simple).
Que le flag utf8 soit activé ou non, en interne, la valeur d'un
scalaire de type chaîne est toujours une suite d'octets. Et on peut y
accéder en tant que suite d'octets (via les fonctions qui manipulent
les octets des scalaires). Maintenant pour toutes les fonctions qui
manipulent des chaînes, c'est transparent.
La seule et unique raison pour laquelle on peut/doit faire appel à
"use utf8;" est lorsque le code du script contient des trucs encodés
en utf8.
C'est la situation la plus courante (mais pas obligatoirement la plus
simple).
Que le flag utf8 soit activé ou non, en interne, la valeur d'un
scalaire de type chaîne est toujours une suite d'octets. Et on peut y
accéder en tant que suite d'octets (via les fonctions qui manipulent
les octets des scalaires). Maintenant pour toutes les fonctions qui
manipulent des chaînes, c'est transparent.
La seule et unique raison pour laquelle on peut/doit faire appel à
"use utf8;" est lorsque le code du script contient des trucs encodés
en utf8.
C'est la situation la plus courante (mais pas obligatoirement la plus
simple).
Ok. Bon, en fait ce que je ne comprends pas c'est ce qui est censé se passer
si on veut faire des opérations (par exemple 'eq') impliquant une chaîne
qui n'a pas le flag utf8 et une qui l'a. Mettons que $sans soit une chaîne
sans flag utf8 qui contient l'octet e9, et $avec une chaîne avec qui
contient le caractère "é". Je demande si ($avec eq $sans) : qu'est censé
faire Perl et surtout pourquoi ? Et est-ce que ça dépend de la machine,
puisque dans un article précédent tu parlais d'encodage « natif (à la
machine) » ?
J'ai l'impression que quand on lit et écrit des fichiers ouverts avec
open(), il suffit de préciser systématiquement l'encodage avec :encoding()
à l'ouverture pour que tout se passe bien (la difficulté étant d'y penser
et surtout de connaître l'encodage). Quels sont les autres cas où c'est
plus compliqué ?
Ok. Bon, en fait ce que je ne comprends pas c'est ce qui est censé se passer
si on veut faire des opérations (par exemple 'eq') impliquant une chaîne
qui n'a pas le flag utf8 et une qui l'a. Mettons que $sans soit une chaîne
sans flag utf8 qui contient l'octet e9, et $avec une chaîne avec qui
contient le caractère "é". Je demande si ($avec eq $sans) : qu'est censé
faire Perl et surtout pourquoi ? Et est-ce que ça dépend de la machine,
puisque dans un article précédent tu parlais d'encodage « natif (à la
machine) » ?
J'ai l'impression que quand on lit et écrit des fichiers ouverts avec
open(), il suffit de préciser systématiquement l'encodage avec :encoding()
à l'ouverture pour que tout se passe bien (la difficulté étant d'y penser
et surtout de connaître l'encodage). Quels sont les autres cas où c'est
plus compliqué ?
Ok. Bon, en fait ce que je ne comprends pas c'est ce qui est censé se passer
si on veut faire des opérations (par exemple 'eq') impliquant une chaîne
qui n'a pas le flag utf8 et une qui l'a. Mettons que $sans soit une chaîne
sans flag utf8 qui contient l'octet e9, et $avec une chaîne avec qui
contient le caractère "é". Je demande si ($avec eq $sans) : qu'est censé
faire Perl et surtout pourquoi ? Et est-ce que ça dépend de la machine,
puisque dans un article précédent tu parlais d'encodage « natif (à la
machine) » ?
J'ai l'impression que quand on lit et écrit des fichiers ouverts avec
open(), il suffit de préciser systématiquement l'encodage avec :encoding()
à l'ouverture pour que tout se passe bien (la difficulté étant d'y penser
et surtout de connaître l'encodage). Quels sont les autres cas où c'est
plus compliqué ?
Ce que représente l'octet de valeur hexa 'e9' dépend de l'encodage
natif de la machine.
Ce que représente l'octet de valeur hexa 'e9' dépend de l'encodage
natif de la machine.
Ce que représente l'octet de valeur hexa 'e9' dépend de l'encodage
natif de la machine.
Paul Gaborit wrote in message :Ce que représente l'octet de valeur hexa 'e9' dépend de l'encodage
natif de la machine.
À condition d'avoir « use locale », ce qui est se tirer une balle dans le
pied à la base. Sinon, ça représente juste un pseudo-caractère n'appartenant
à aucune catégorie pertinente.
Paul Gaborit wrote in message <wt94p17yvhh.fsf@marceau.enstimac.fr>:
Ce que représente l'octet de valeur hexa 'e9' dépend de l'encodage
natif de la machine.
À condition d'avoir « use locale », ce qui est se tirer une balle dans le
pied à la base. Sinon, ça représente juste un pseudo-caractère n'appartenant
à aucune catégorie pertinente.
Paul Gaborit wrote in message :Ce que représente l'octet de valeur hexa 'e9' dépend de l'encodage
natif de la machine.
À condition d'avoir « use locale », ce qui est se tirer une balle dans le
pied à la base. Sinon, ça représente juste un pseudo-caractère n'appartenant
à aucune catégorie pertinente.
Le script suivant n'utilise pas de 'locale' particulieur et affiche
pourtant bien 'ok', non ?
use charnames ":full";
print "okn" if "x{e9}" eq "N{LATIN SMALL LETTER E WITH ACUTE}";
Le script suivant n'utilise pas de 'locale' particulieur et affiche
pourtant bien 'ok', non ?
use charnames ":full";
print "okn" if "x{e9}" eq "N{LATIN SMALL LETTER E WITH ACUTE}";
Le script suivant n'utilise pas de 'locale' particulieur et affiche
pourtant bien 'ok', non ?
use charnames ":full";
print "okn" if "x{e9}" eq "N{LATIN SMALL LETTER E WITH ACUTE}";
Paul Gaborit wrote in message :Le script suivant n'utilise pas de 'locale' particulieur et affiche
pourtant bien 'ok', non ?
use charnames ":full";
print "okn" if "x{e9}" eq "N{LATIN SMALL LETTER E WITH ACUTE}";
Oui, mais ça ne prouve pas ce que tu disais.
D'une part, ça ne dépend pas de l'encodage de la machine : ton script répond
ok même en contexte UTF-8 ou KOI8-R, ce qui prouve qu'il se comporte
systématiquement comme si le x{e9} était de l'ISO-8859-1 et pas suivant
l'encodage de la machine.
D'autre part, le script suivant :
use charnames ":full";
print "okn" if uc("x{e9}") eq uc("N{LATIN SMALL LETTER E WITH ACUTE}");
ne répond pas ok, parce que les opérateurs « linguistiques » sont inopérants
sur les octets hors locale.
Les règles sont, il me semble :
- Sur une chaîne de caractères Unicode (celles où utf8::is_utf8 répond oui),
les opérateurs linguistiques fonctionnent suivant les catégories Unicode.
- Sur une chaîne d'octets, avec use locale, les opérateurs linguistiques
fonctionnent suivant la locale ambiante autant que possible.
- Sur une chaîne d'octets, sans use locale, les opérateurs linguistiques
s'appliquent sur l'ASCII, et considèrent le reste de la manière la plus
conservative possible.
- Quand une chaîne d'octets est passée là où une chaîne de caractères
Unicode est attendue, elle est upgradée en convertissant les valeurs
d'octets en valeurs de caractères (ce qui est équivalent à considérer
qu'elle était encodée en ISO-8859-1).
- Quand une chaîne d'octets est combinée ou comparée à une chaîne de
caractères Unicode, elle est upgradée de la même façon.
- Quand une chaîne de caractères Unicode est passée là où seule une chaîne
d'octets est attendue (dans les filehandles sans couche d'encodage), si
elle est entièrement constituée de caractères représentables en
ISO-8859-1, elle est downgradée de la manière réciproque à ce qui
précède ; si elle ne l'est pas, un warning est émis et elle est downgradée
en prenant la représentation UTF-8
Personnellement, je considère comme buggés les programmes un tant soit peu
ambitieux qui comptent sur l'upgrade automatique ou, encore pire, sa
réciproque. J'aimerais pouvoir obtenir un warning chaque fois qu'il y a
upgrade ou downgrade automatique ou qu'un opérateur linguistique est
appliqué à une chaîne d'octets.
Paul Gaborit wrote in message <wt94p16ufab.fsf@marceau.enstimac.fr>:
Le script suivant n'utilise pas de 'locale' particulieur et affiche
pourtant bien 'ok', non ?
use charnames ":full";
print "okn" if "x{e9}" eq "N{LATIN SMALL LETTER E WITH ACUTE}";
Oui, mais ça ne prouve pas ce que tu disais.
D'une part, ça ne dépend pas de l'encodage de la machine : ton script répond
ok même en contexte UTF-8 ou KOI8-R, ce qui prouve qu'il se comporte
systématiquement comme si le x{e9} était de l'ISO-8859-1 et pas suivant
l'encodage de la machine.
D'autre part, le script suivant :
use charnames ":full";
print "okn" if uc("x{e9}") eq uc("N{LATIN SMALL LETTER E WITH ACUTE}");
ne répond pas ok, parce que les opérateurs « linguistiques » sont inopérants
sur les octets hors locale.
Les règles sont, il me semble :
- Sur une chaîne de caractères Unicode (celles où utf8::is_utf8 répond oui),
les opérateurs linguistiques fonctionnent suivant les catégories Unicode.
- Sur une chaîne d'octets, avec use locale, les opérateurs linguistiques
fonctionnent suivant la locale ambiante autant que possible.
- Sur une chaîne d'octets, sans use locale, les opérateurs linguistiques
s'appliquent sur l'ASCII, et considèrent le reste de la manière la plus
conservative possible.
- Quand une chaîne d'octets est passée là où une chaîne de caractères
Unicode est attendue, elle est upgradée en convertissant les valeurs
d'octets en valeurs de caractères (ce qui est équivalent à considérer
qu'elle était encodée en ISO-8859-1).
- Quand une chaîne d'octets est combinée ou comparée à une chaîne de
caractères Unicode, elle est upgradée de la même façon.
- Quand une chaîne de caractères Unicode est passée là où seule une chaîne
d'octets est attendue (dans les filehandles sans couche d'encodage), si
elle est entièrement constituée de caractères représentables en
ISO-8859-1, elle est downgradée de la manière réciproque à ce qui
précède ; si elle ne l'est pas, un warning est émis et elle est downgradée
en prenant la représentation UTF-8
Personnellement, je considère comme buggés les programmes un tant soit peu
ambitieux qui comptent sur l'upgrade automatique ou, encore pire, sa
réciproque. J'aimerais pouvoir obtenir un warning chaque fois qu'il y a
upgrade ou downgrade automatique ou qu'un opérateur linguistique est
appliqué à une chaîne d'octets.
Paul Gaborit wrote in message :Le script suivant n'utilise pas de 'locale' particulieur et affiche
pourtant bien 'ok', non ?
use charnames ":full";
print "okn" if "x{e9}" eq "N{LATIN SMALL LETTER E WITH ACUTE}";
Oui, mais ça ne prouve pas ce que tu disais.
D'une part, ça ne dépend pas de l'encodage de la machine : ton script répond
ok même en contexte UTF-8 ou KOI8-R, ce qui prouve qu'il se comporte
systématiquement comme si le x{e9} était de l'ISO-8859-1 et pas suivant
l'encodage de la machine.
D'autre part, le script suivant :
use charnames ":full";
print "okn" if uc("x{e9}") eq uc("N{LATIN SMALL LETTER E WITH ACUTE}");
ne répond pas ok, parce que les opérateurs « linguistiques » sont inopérants
sur les octets hors locale.
Les règles sont, il me semble :
- Sur une chaîne de caractères Unicode (celles où utf8::is_utf8 répond oui),
les opérateurs linguistiques fonctionnent suivant les catégories Unicode.
- Sur une chaîne d'octets, avec use locale, les opérateurs linguistiques
fonctionnent suivant la locale ambiante autant que possible.
- Sur une chaîne d'octets, sans use locale, les opérateurs linguistiques
s'appliquent sur l'ASCII, et considèrent le reste de la manière la plus
conservative possible.
- Quand une chaîne d'octets est passée là où une chaîne de caractères
Unicode est attendue, elle est upgradée en convertissant les valeurs
d'octets en valeurs de caractères (ce qui est équivalent à considérer
qu'elle était encodée en ISO-8859-1).
- Quand une chaîne d'octets est combinée ou comparée à une chaîne de
caractères Unicode, elle est upgradée de la même façon.
- Quand une chaîne de caractères Unicode est passée là où seule une chaîne
d'octets est attendue (dans les filehandles sans couche d'encodage), si
elle est entièrement constituée de caractères représentables en
ISO-8859-1, elle est downgradée de la manière réciproque à ce qui
précède ; si elle ne l'est pas, un warning est émis et elle est downgradée
en prenant la représentation UTF-8
Personnellement, je considère comme buggés les programmes un tant soit peu
ambitieux qui comptent sur l'upgrade automatique ou, encore pire, sa
réciproque. J'aimerais pouvoir obtenir un warning chaque fois qu'il y a
upgrade ou downgrade automatique ou qu'un opérateur linguistique est
appliqué à une chaîne d'octets.
Mais tu confonds 'locale' et encodage natif. Sur une machine donnée,
les différents utilisateurs peuvent choisir leur 'locale' comme ils le
souhaitent. Certains utilise UTF-8 d'autre KOI8-R, etc. Cela n'empêche
pas perl de considérer que l'encodage natif est ISO-8859-1.
En fait, à ma connaissance, perl considère toujours que l'encodage
natif est ISO-8859-1 sauf sur les machines utilisant l'EBCDIC (et
peut-être celles sous VMS que je ne connais pas).
use charnames ":full";
print "okn" if uc("x{e9}") eq uc("N{LATIN SMALL LETTER E WITH ACUTE}");
ne répond pas ok, parce que les opérateurs « linguistiques » sont inopérants
sur les octets hors locale.
Là, je ne vois vraiment pas ce que tu veux dire... Veux-tu dire que ta
machine ne réponds pas 'ok' ? Ou que l'opérateur 'eq' ne compare pas
vraiment les deux chaînes ? Autres choses ?
L'usage des 'locale' (que ce soit via 'use locale' ou via la couche
d'I/O ':locale') ajoute une couche d'interprétation supplémentaire qui
complexifie encore les choses. Vu que ce n'était pas l'objet de la
question, je propose qu'on en discute après avoir éclaircie la partie
encodage natif/encodage utf8 interne de perl.
Pour les opérateurs de chaînes, il n'y a pas de chaînes d'octets. Il y
a les chaînes en encodage natif (flag utf8 à 'off')
et les chaînes en
UTF8 (flag utf8 à 'on').
Il se trouve que les encodages natifs actuels ont toujours une
représentation qui a un caractère associe un seul octet. Si bien que
dans les faits, une chaîne en encodage natif est strictement
équivalente à une suite d'octets. Mais rien ne dit que ce sera
toujours le cas....
Pourquoi ne pas compter dessus puisque la conversion est bien faite ?
Mais tu confonds 'locale' et encodage natif. Sur une machine donnée,
les différents utilisateurs peuvent choisir leur 'locale' comme ils le
souhaitent. Certains utilise UTF-8 d'autre KOI8-R, etc. Cela n'empêche
pas perl de considérer que l'encodage natif est ISO-8859-1.
En fait, à ma connaissance, perl considère toujours que l'encodage
natif est ISO-8859-1 sauf sur les machines utilisant l'EBCDIC (et
peut-être celles sous VMS que je ne connais pas).
use charnames ":full";
print "okn" if uc("x{e9}") eq uc("N{LATIN SMALL LETTER E WITH ACUTE}");
ne répond pas ok, parce que les opérateurs « linguistiques » sont inopérants
sur les octets hors locale.
Là, je ne vois vraiment pas ce que tu veux dire... Veux-tu dire que ta
machine ne réponds pas 'ok' ? Ou que l'opérateur 'eq' ne compare pas
vraiment les deux chaînes ? Autres choses ?
L'usage des 'locale' (que ce soit via 'use locale' ou via la couche
d'I/O ':locale') ajoute une couche d'interprétation supplémentaire qui
complexifie encore les choses. Vu que ce n'était pas l'objet de la
question, je propose qu'on en discute après avoir éclaircie la partie
encodage natif/encodage utf8 interne de perl.
Pour les opérateurs de chaînes, il n'y a pas de chaînes d'octets. Il y
a les chaînes en encodage natif (flag utf8 à 'off')
et les chaînes en
UTF8 (flag utf8 à 'on').
Il se trouve que les encodages natifs actuels ont toujours une
représentation qui a un caractère associe un seul octet. Si bien que
dans les faits, une chaîne en encodage natif est strictement
équivalente à une suite d'octets. Mais rien ne dit que ce sera
toujours le cas....
Pourquoi ne pas compter dessus puisque la conversion est bien faite ?
Mais tu confonds 'locale' et encodage natif. Sur une machine donnée,
les différents utilisateurs peuvent choisir leur 'locale' comme ils le
souhaitent. Certains utilise UTF-8 d'autre KOI8-R, etc. Cela n'empêche
pas perl de considérer que l'encodage natif est ISO-8859-1.
En fait, à ma connaissance, perl considère toujours que l'encodage
natif est ISO-8859-1 sauf sur les machines utilisant l'EBCDIC (et
peut-être celles sous VMS que je ne connais pas).
use charnames ":full";
print "okn" if uc("x{e9}") eq uc("N{LATIN SMALL LETTER E WITH ACUTE}");
ne répond pas ok, parce que les opérateurs « linguistiques » sont inopérants
sur les octets hors locale.
Là, je ne vois vraiment pas ce que tu veux dire... Veux-tu dire que ta
machine ne réponds pas 'ok' ? Ou que l'opérateur 'eq' ne compare pas
vraiment les deux chaînes ? Autres choses ?
L'usage des 'locale' (que ce soit via 'use locale' ou via la couche
d'I/O ':locale') ajoute une couche d'interprétation supplémentaire qui
complexifie encore les choses. Vu que ce n'était pas l'objet de la
question, je propose qu'on en discute après avoir éclaircie la partie
encodage natif/encodage utf8 interne de perl.
Pour les opérateurs de chaînes, il n'y a pas de chaînes d'octets. Il y
a les chaînes en encodage natif (flag utf8 à 'off')
et les chaînes en
UTF8 (flag utf8 à 'on').
Il se trouve que les encodages natifs actuels ont toujours une
représentation qui a un caractère associe un seul octet. Si bien que
dans les faits, une chaîne en encodage natif est strictement
équivalente à une suite d'octets. Mais rien ne dit que ce sera
toujours le cas....
Pourquoi ne pas compter dessus puisque la conversion est bien faite ?