Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

"x{e9}" n'est pas egal a "é"

22 réponses
Avatar
luc2
bonjour,

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",

demonstration :

use Data::Dumper;
use Locale::TextDomain('messages');

my $msg = "numéro";
$msg = decode( "utf-8", $msg, 4 );
my $msg2 = "numéro";

print Dumper $msg; # $VAR1 = "num\x{e9}ro";
print Dumper $msg2; # $VAR1 = 'numéro';

if( $msg eq $msg2 )
{
print "msg eq msg2\n"; # c'est egal
}

$msg = __x( $msg );
$msg2 = __x( $msg2 );

print "$msg\n"; # c'est pas egal
print "$msg2\n"; # c'est pas egal

10 réponses

1 2 3
Avatar
Paul Gaborit
À (at) 11 Dec 2008 12:55:07 GMT,
luc2 écrivait (wrote):
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",



Le comportement que vous décrivez n'a rien de surprenant. Reste à
savoir de quelles biblitohèques vous parlez...

J'ai modifié votre script de démonstration pour ne pas dépendre de
Local::TextDomain :

########################################
#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;
use charnames ":full";
use Encode qw/encode decode is_utf8/;

sub compare_msg {
my ($m1, $m2) = @_;
print "---n";
print "flag utf8 sur $m1n" if is_utf8($m1);
print "flag utf8 sur $m2n" if is_utf8($m2);
print Dumper $m1; # $VAR1 = "numx{e9}ro";
print Dumper $m2; # $VAR1 = 'numéro';
if( $m1 eq $m2 ) {
print "$m1 eq $m2n"; # c'est egal
}
my %h;
print length $m1, " ", length $m2, "n";
$h{$m1} = 1;
$h{$m2} = 2;
print "$h{$m1} $h{$m2}n"
}

# $msg1 avec le flag utf8 'on'
# $msg2 avcec le flag utf8 'off' (en codage natif)
my $msg1 = "numN{LATIN SMALL LETTER E WITH ACUTE}ro";
my $msg2 = "numéro";
compare_msg($msg1, $msg2);

# on transforme $msg2 " flag utf8 'on'
$msg2 = decode("iso-8859-1", $msg2);
compare_msg($msg1, $msg2);

# on transforme $msg1 et $msg2 (flag utf8 'off')
# ils sont tous les deux en codage natif
$msg1 = encode("iso-8859-1", $msg1);
$msg2 = encode("iso-8859-1", $msg2);
compare_msg($msg1, $msg2);
########################################

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) et en encodage utf8 (un UTF-8 amélioré pour perl). perl
sait si la chaîne est dans un format ou un autre via un flag interne
'utf8' attaché à chaque chaîne. C'est ce que montre ma petite
subroutine 'compare_msg'.

D'autre part, Data::Dumper a pour but (entre autres) de générer un
code Perl correct. Lorsqu'il constate qu'une chaîne est en utf8, il
traduit tous les caractères supérieurs à 127 par une séquence
x{...}. Par contre, si la chaîne est en encodage natif, il l'affiche
tel quel (sauf les caractères de contrôle). D'où la différence
d'affichage entre 'é' et 'x{e9}' qui représente pourtant bien le
*même* caractère en 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...

Dans votre cas, je pencherai pour chercher comment Local::TextDomain
détermine l'encodage des fichiers de messages qu'il lit et utilise
pour faire les traductions... C'est là qu'est le problème. Et en
creusant un peu, on s'aperçoit que Local::TextDomain fait appel à
Local::Message qui, lui, supprime allègrement sans s'en préoccuper le
flag utf8 d'un message ! Peut-être pour pouvoir utiliser les versions
XS des routines 'gettext' qui ne savent évidemment pas gérer ce flag
utf8 venant de perl.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/&gt;
Perl en français - <http://perl.enstimac.fr/&gt;
Avatar
mpg
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 ?

Manuel.
Avatar
Paul Gaborit
À (at) Sat, 13 Dec 2008 16:20:38 +0100,
mpg écrivait (wrote):
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) ».



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.

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;" ;



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.

- les entrées-sorties.



C'est la situation la plus courante (mais pas obligatoirement la plus
simple).

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 ?



Oui... Le troisième cas qui peut se présenter est beaucoup plus rare :
lorsqu'on fait appel à une bibliothèque externe liée dynamiquement (en
C, C++, Java ou autre). Mais on peut assimiler cela à des
entrées/sorties.

Dernière situation où il faut faire attention (et qui est à l'origine
de cette enfilade) : lorsqu'un code modifie les flags utf8 internes de
perl de manière arbitraire. C'est pour cela que c'est déconseillé !

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/&gt;
Perl en français - <http://perl.enstimac.fr/&gt;
Avatar
mpg
Le (on) samedi 13 décembre 2008 18:24, Paul Gaborit a écrit (wrote) :

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.



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) » ?

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.



Cool, c'est la seule et unique raison pour laquelle je l'utilise :-)

C'est la situation la plus courante (mais pas obligatoirement la plus
simple).



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é ?

Manuel.

PS : du coup, j'ouvre un autre fil sur une question d'encodages...
Avatar
Paul Gaborit
À (at) Sat, 13 Dec 2008 23:15:43 +0100,
mpg écrivait (wrote):
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) » ?



Ce que représente l'octet de valeur hexa 'e9' dépend de l'encodage
natif de la machine. A priori, sur de nombreuses machines qui
utilisent l'encodage iso-8859-1, c'est le caractère 'é' (je n'ai
jamais utilisé/rencontré de machines qui n'utilisaient pas
l'iso-8859-1 comme encodage natif).

Ensuite, ce que montrait mon petit code d'exemple, c'est que cette
$san est considéré par perl comme égale à $avec partout où ces deux
scalaires sont utilisés en tant que chaîne : comparaison par 'eq', clé
de table de hachage, calcul de longueur par 'length', etc.

C'est donc bien transparent...

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é ?



Ça peut être un tout petit peu plus compliqué si le fichier (ou la
connexion réseau) est ouvert par un autre code que le tien. Exemple le
plus évident : STDOUT, STDIN, STDERR. Autre cas : un handler de base
de données qui est ouvert par DBI. Etc.

Par exemple, avec CGI (et tout ce que vient par dessus), STDOUT est
ouvert en mode 'raw' (ce qui est normal). Et là, les deux chaînes
$sans et $avec ne se comporteront plus de manière identique si on les
écrit sur STDIN.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/&gt;
Perl en français - <http://perl.enstimac.fr/&gt;
Avatar
Nicolas George
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.
Avatar
Paul Gaborit
À (at) 14 Dec 2008 10:14:08 GMT,
Nicolas George <nicolas$ écrivait (wrote):
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.



Je ne vois pas le rapport...

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 - <http://perso.enstimac.fr/~gaborit/&gt;
Perl en français - <http://perl.enstimac.fr/&gt;
Avatar
Nicolas George
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.
Avatar
Paul Gaborit
À (at) 15 Dec 2008 09:32:48 GMT,
Nicolas George <nicolas$ écrivait (wrote):
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.



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).

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.



???

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 ?

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.



Oui.

- Sur une chaîne d'octets, avec use locale, les opérateurs linguistiques
fonctionnent suivant la locale ambiante autant que possible.



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.

- 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.



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....

- 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).



L'interprétation des valeurs d'octets en tant que caractères pour les
chaînes avec le flag utf8 à 'off' se fait selon l'encodage natif de la
machine (qui est effectivement ISO-8859-1 sur la plupart des
machines).

- 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.



Effectivement, les opérateurs opérant sur les chaînes savent gérer les
deux types de chaînes (celles avec ou celles sans le flag utf8).

- 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



Oui. Par défaut pour STDOUT (sans locale), c'est l'encodage natif de
la machine. Ce qui permet de faire le downgrade correct (lorsque c'est
faisable) ou d'émettre un avertissement si ce n'est pas faisable.

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.



Pourquoi ne pas compter dessus puisque la conversion est bien faite ?
L'avertissement est bien émis si la conversion est impossible.

En fait, je ne comprends pas vraiment où nous ne sommes pas
d'accord. Tous les faits que tu énumères me semblent conformes par
rapport à ce que j'expliquais. Il n'y a que notre manière de les
interprèter qui peuvent différer. Je pense pourtant que mes
explications sont plus proches de ce qu'explique la documentation (et
de la manière dont cela est réellement implémenté).

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/&gt;
Perl en français - <http://perl.enstimac.fr/&gt;
Avatar
Nicolas George
En fait, je pense que nous différons presque uniquement sur le vocabulaire.
Tu utilises le jargon de la doc de perl, mais ce jargon est globalement très
mal choisi, et sans le contexte il est dramatiquement imprécis voire fautif.


Paul Gaborit wrote in message :
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.



Quand on installe une Ubuntu, l'encodage du système sera en UTF-8 : les
fichiers de configuration, les comptes utilisateurs par défaut, les
filesystems bizarres montés depuis une clef USB, tout ceci sera en UTF-8, et
cet état de fait sera correctement indiqué dans les locales. On peut donc
très clairement dire que l'encodage natif de la machine est UTF-8.

Donc il faudrait dire « encodage natif de perl sur cette architecture »
plutôt que « de la machine ».

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).



En fait, pour moi, tout ce qui n'est pas POSIX inexiste purement et
simplement.

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 ?



Aucune machine ne doit répondre ok, parce que : uc("x{e9}"), c'est
"x{e9}", sans changement, alors que uc("N{LATIN SMALL LETTER E WITH
ACUTE}"), c'est "N{LATIN CAPITAL LETTER E WITH ACUTE}".

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.



Oui, bien sûr, mais je voulais donner des règles complètes.

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')



Il est faux de dire que ces chaînes sont dans l'encodage natif, sous-entendu
ISO-8859-1 sur les architectures POSIX : si c'était de l'ISO-8859-1, uc
reconnaîtrait les caractères accentués, ce qui n'est pas le cas.

On pourrait parler de chaînes d'ASCII-étendu, mais je préfère parler de
chaînes d'octets pour souligner qu'il ne faut pas s'attendre à ce que les
opérateurs linguistiques fonctionnent

et les chaînes en
UTF8 (flag utf8 à 'on').



Il est à peu près vrai que ces chaînes sont en UTF-8 en interne, mais _on
s'en fiche_ : l'API ne devrait normalement pas (et c'est à peu près le cas)
nous laisser toucher à la représentation interne (sauf cas de bindings avec
d'autres langages, évidemment), donc il vaut mieux parler de l'aspect
pratique de l'interface : chaînes de caractères Unicode.

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....



Si, quelque chose nous dit que ce sera toujours le cas : ça casserait toutes
les manipulations de données binaires.

Pourquoi ne pas compter dessus puisque la conversion est bien faite ?



Parce que ça ne rend pas du tout les choses explicites, donc c'est peu
lisible et auto-documenté, donc fragile.
1 2 3