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

À (at) 15 Dec 2008 15:32:14 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):

En fait, je pense que nous différons presque uniquement sur le vocabulaire.

C'est bien ce qui m'avait semblé....

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.

C'est vrai... Mais donc un forum Perl, tu comprendras que je préfère
utiliser le jargon/vocabulaire de la doc Perl. ;-)

Paul Gaborit wrote in message <wt9y6yh8un7.fsf@marceau.enstimac.fr>:

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

Alors là, je ne suis vraiment pas d'accord avec toi. Le système
d'exploitation (Ubuntu. *BSD, Solaris, etc.) n'a aucun a priori sur
les encodages utilisés (si ce n'est peut-être l'ASCII). Pour le reste,
c'est entièrement configurable par application, par utilisateur,
etc. À chacun ses goûts et ses besoins... Personnellement, j'utilise
utf-8 dans certains cas et iso-8859-1 dans d'autres. Mais sur la même
machine, il y a d'autres utilisateurs qui utilsisent carrément autre
chose (du cp1252 ou des trucs pour le chinois dont je ne me souviens
plus du nom...). Et le plus fort, c'est que ça marche.

Par ailleurs, la plupart des filesystem ignorent totalement la notion
d'encodage des noms de fichiers (et heureusement d'ailleurs).

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.

C'est se couper d'une bonne partie des machines existantes (et même,
dans l'absolu, de toutes car aucun système ne respecte entièrement
POSIX ;-)).

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

Exact. En fait, je n'avais pas vu que tu avais ajouté l'appel à 'uc'
dans mon exemple de code ! Et effectivement, ça change tout.

Mais 'uc', 'lc' et 'ucfirst' sont des cas spéciaux car ils doivent
savoir mettre en correspondance caractères majuscule et minuscule. Et
là, ça dépend du 'locale'. J'étais effectivement un peu optimiste en
affirmant que toutes les fonctions de traitement de chaînes savaient
gérer les chaînes avec ou sans le flag 'utf8'.

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.

D'où le lien avec 'uc'... Je comprends mieux. Désolé d'avoir zappé ce
détail qui a pourtant toute son importance.

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 peut considérer cela comme un défaut de 'uc' (qu'on peut pallier
par les 'locale' mais qui pose alors d'autre problème). Je ne sais pas
ce qui à amener à ce choix. En fait, je me demande si ce n'est pas
historique parce que ce fonctionnement était déjà comme ça avant
l'introduction de l'utf8 dans Perl.

De toutes manières, le passage à utf-8 est une longue route pour les
systèmes (ça vient peu à peu) et difficile dans tous les
langages. Personnellement, par rapport à d'autres langages, je trouve
que Perl ne s'en sort pas trop mal même si il doit traîner quelques
boulets historiques. La compatibilité ascendante à toujours un prix.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Paul Gaborit wrote in message <wt9myex8hrb.fsf@marceau.enstimac.fr>:

Alors là, je ne suis vraiment pas d'accord avec toi. Le système
d'exploitation (Ubuntu. *BSD, Solaris, etc.) n'a aucun a priori sur
les encodages utilisés (si ce n'est peut-être l'ASCII). Pour le reste,
c'est entièrement configurable par application, par utilisateur,
etc. À chacun ses goûts et ses besoins... Personnellement, j'utilise
utf-8 dans certains cas et iso-8859-1 dans d'autres. Mais sur la même
machine, il y a d'autres utilisateurs qui utilsisent carrément autre
chose (du cp1252 ou des trucs pour le chinois dont je ne me souviens
plus du nom...). Et le plus fort, c'est que ça marche.

Je ne suis pas d'accord : presque tout est configurable à différents niveau,
mais il y a néanmoins une valeur par défaut commune à l'ensemble du système.

Par ailleurs, la plupart des filesystem ignorent totalement la notion
d'encodage des noms de fichiers (et heureusement d'ailleurs).

Certains, hélas, en tiennent compte.

Mais 'uc', 'lc' et 'ucfirst' sont des cas spéciaux car ils doivent
savoir mettre en correspondance caractères majuscule et minuscule.

J'aurais pu te faire la même chose avec « s/w/!/g », qui n'a pas de
correspondance à faire : w matche N{LATIN SMALL LETTER E WITH ACUTE}, pas
x{e9}.

D'où le lien avec 'uc'... Je comprends mieux. Désolé d'avoir zappé ce
détail qui a pourtant toute son importance.

J'avais pourtant bien écrit « opérateurs linguistiques » un peu partout.

On peut considérer cela comme un défaut de 'uc' (qu'on peut pallier
par les 'locale' mais qui pose alors d'autre problème). Je ne sais pas
ce qui à amener à ce choix. En fait, je me demande si ce n'est pas
historique parce que ce fonctionnement était déjà comme ça avant
l'introduction de l'utf8 dans Perl.

C'est clairement historique, oui.

De toutes manières, le passage à utf-8 est une longue route pour les
systèmes (ça vient peu à peu) et difficile dans tous les
langages. Personnellement, par rapport à d'autres langages, je trouve
que Perl ne s'en sort pas trop mal même si il doit traîner quelques
boulets historiques. La compatibilité ascendante à toujours un prix.

La manière de faire de Perl depuis la version 5.8 est vraiment excellente,
je n'en ai pas rencontré de meilleure dans d'autres langages. C'est juste le
vocabulaire pour désigner les différentes notions utilisées qui est très mal
choisi.

À (at) 15 Dec 2008 20:08:23 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):

Je ne suis pas d'accord : presque tout est configurable à différents niveau,
mais il y a néanmoins une valeur par défaut commune à l'ensemble du système.

Si cela existe, j'aimerai bien savoir où... J'ai plusieurs Ubuntu,
FreeBSD et Solaris sous la main et je ne vois aucun fichier de
configuration où on ait à choisir un encodage utilisé de manière
globale par le système.

Par ailleurs, la plupart des filesystem ignorent totalement la notion
d'encodage des noms de fichiers (et heureusement d'ailleurs).

Certains, hélas, en tiennent compte.

Là, je suis d'accord... ;-)

Mais 'uc', 'lc' et 'ucfirst' sont des cas spéciaux car ils doivent
savoir mettre en correspondance caractères majuscule et minuscule.

J'aurais pu te faire la même chose avec « s/w/!/g », qui n'a pas de
correspondance à faire : w matche N{LATIN SMALL LETTER E WITH ACUTE}, pas
x{e9}.

D'où le lien avec 'uc'... Je comprends mieux. Désolé d'avoir zappé ce
détail qui a pourtant toute son importance.

J'avais pourtant bien écrit « opérateurs linguistiques » un peu partout.

C'est vrai que l'aspect linguistique (limite des mots, changement de
casse et surtout ordre des chaînes) est plus exigeant que la simple
manipulation de chaînes (comparaison, comptage des caractères,
affichage, utilisation comme clé, etc.).

Mais là encore, avec 'use locale', on peut faire pas mal de choses de
manière assez souple.

La manière de faire de Perl depuis la version 5.8 est vraiment excellente,
je n'en ai pas rencontré de meilleure dans d'autres langages. C'est juste le
vocabulaire pour désigner les différentes notions utilisées qui est très mal
choisi.

De ce que j'en ai vu, Python se débrouille pas mal non plus.... Mais
je préfère Perl. ;-)

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Le (on) lundi 15 décembre 2008 18:34, Paul Gaborit a écrit (wrote) :

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.

C'est vrai... Mais donc un forum Perl, tu comprendras que je préfère
utiliser le jargon/vocabulaire de la doc Perl. ;-)

Si je peux me permettre, n'étant pas encore très familier avec le jargon
Perl, j'étais en effet très perturbé par la notion d'encodage « natif à la
machine », parce que je ne vois vraiment pas ce que ça veut dire (ou alors
selon moi ça n'existe pas, comme tu le dis plus bas).

En fait, concrêtement, c'est une valeur définie à la compilation de Perl, en
fonction de l'architecture cible ?

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

J'avoue que ça me parle beaucoup plus comme notion (après, que ça soit la
réalité ou pas, je ne sais pas).

En gros vous êtes quand même tous les deux d'accord sur le fait, qui me
paraît essentiel, que pour les chaînes qui n'ont pas le flag utf8, le
comportement n'est pas identique partout.

c'est entièrement configurable par application, par utilisateur,

Il me semble aussi. Et la valeur par défaut si elle existe n'est respectée
que par les applications qui prennent la peine de la respecter. On parlait
de (La)TeX par exemple : je serai fort surpris d'apprendre qu'il s'attend à
un fichier d'entrée en UTF-8, même sur un Ubuntu récente ;-)

plus du nom...). Et le plus fort, c'est que ça marche.

À condition de savoir ce qu'on fait, et de faire ce qu'il faut pour que ça
marche, d'où l'intérêt du fil :-)

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 peut considérer cela comme un défaut de 'uc' (qu'on peut pallier
par les 'locale' mais qui pose alors d'autre problème).

Ah, donc quand même, pour une chaîne dans ce que le jargon Perl
appelle « encodage natif », il y a des fonctions qui vont fonctionner comme
si c'était effectivement une chaîne de caractères, et d'autres plutôt comme
si c'était une suite d'octets dont ceux de valeur >127 n'ont pas vraiment
de signification.

Au final, entre ça et le comportement potentiellement différent selon les
architectures, l'encodage natif c'est un peu cradobeurk. Ce qui n'est pas
une grande surprise en fait... Mais dans un sens je trouve ça dangereux que
des fois ça ait l'air de marcher !

Manuel.

À (at) Tue, 16 Dec 2008 02:21:40 +0100,
mpg <mpg-news@elzevir.fr> écrivait (wrote):

Si je peux me permettre, n'étant pas encore très familier avec le
jargon Perl, j'étais en effet très perturbé par la notion d'encodage
« natif à la machine », parce que je ne vois vraiment pas ce que ça
veut dire (ou alors selon moi ça n'existe pas, comme tu le dis plus
bas).

En fait, concrêtement, c'est une valeur définie à la compilation de Perl, en
fonction de l'architecture cible ?

C'est exactement ça. Et on ne peut pas choisir. C'est prédéfini pour
chaque couple architecture/OS.

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

J'avoue que ça me parle beaucoup plus comme notion (après, que ça soit la
réalité ou pas, je ne sais pas).

En gros vous êtes quand même tous les deux d'accord sur le fait, qui me
paraît essentiel, que pour les chaînes qui n'ont pas le flag utf8, le
comportement n'est pas identique partout.

Entre deux couples architectures/OS différents, le comportement peut
différé. Et si on pousse plus loin, sur les machines EBCDIC, perl
utilise de l'UTF-8 basé EBCDIC et non basé ASCII.

Ah, donc quand même, pour une chaîne dans ce que le jargon Perl
appelle « encodage natif », il y a des fonctions qui vont fonctionner comme
si c'était effectivement une chaîne de caractères, et d'autres plutôt comme
si c'était une suite d'octets dont ceux de valeur >127 n'ont pas vraiment
de signification.

En fait, c'est qu'on peut différencier les comportements vis-à-vis des
caractères considérés isolément ou considérés linguistiquement.

Au final, entre ça et le comportement potentiellement différent selon les
architectures, l'encodage natif c'est un peu cradobeurk. Ce qui n'est pas
une grande surprise en fait... Mais dans un sens je trouve ça dangereux que
des fois ça ait l'air de marcher !

Mais comme tu le disais si bien, le principal est de définir
correctement les encodages des E/S (donc ce qu'on voit de
l'extérieur). En fait, on trouve ces deux paragraphes dans
'perlunicode' :

In future, Perl-level operations will be expected to work with
characters rather than bytes.

However, as an interim compatibility measure, Perl aims to provide
a safe migration path from byte semantics to character semantics
for programs. For operations where Perl can unambiguously decide
that the input data are characters, Perl switches to character
semantics. For operations where this determination cannot be made
without additional information from the user, Perl decides in favor
of compatibility and chooses to use byte semantics.

On a donc bien un comportement un peu 'cradobeurk' pour certains
opérateurs pour des raisons de compatibilité.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Paul Gaborit wrote in message <wt9iqplexwp.fsf@marceau.enstimac.fr>:

Si cela existe, j'aimerai bien savoir où... J'ai plusieurs Ubuntu,
FreeBSD et Solaris sous la main et je ne vois aucun fichier de
configuration où on ait à choisir un encodage utilisé de manière
globale par le système.

Sur Ubuntu, c'est /etc/default/locale qui détermine la locale (et donc
l'encodage) par défaut commun à tous les utilisateurs, qui sera aussi la
locale du display manager, qui impliquera l'encodage par défaut de la
console texte, etc.

À (at) 16 Dec 2008 09:26:29 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):

Paul Gaborit wrote in message <wt9iqplexwp.fsf@marceau.enstimac.fr>:

Si cela existe, j'aimerai bien savoir où... J'ai plusieurs Ubuntu,
FreeBSD et Solaris sous la main et je ne vois aucun fichier de
configuration où on ait à choisir un encodage utilisé de manière
globale par le système.

Sur Ubuntu, c'est /etc/default/locale qui détermine la locale (et donc
l'encodage) par défaut commun à tous les utilisateurs, qui sera aussi la
locale du display manager, qui impliquera l'encodage par défaut de la
console texte, etc.

Mais c'est un encodage par défaut (c'est à dire en l'absence de
réglage plus spécifique). Aucun soft système n'exige le choix d'un
encodage spécifique à ce niveau pour fonctionner (à mon avis, les
softs systèmes n'utilisent même pas ce fichier). Je suis même
quasiment certain que tout le système fonctionne parfaitement en
l'absence de ce fichier.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Paul Gaborit wrote in message <wt93ago8nvo.fsf@marceau.enstimac.fr>:

Mais c'est un encodage par défaut (c'est à dire en l'absence de
réglage plus spécifique). Aucun soft système n'exige le choix d'un
encodage spécifique à ce niveau pour fonctionner

Bien sûr. C'est pour ça que je l'évoque pour l'encodage « natif » de la
machine, pas de l'encodage « obligatoire ». Le fait est que, quand tu
débarques sur une machine, l'immense majorité des fichiers texte seront dans
l'encodage indiqué ici, et sauf manipulation explicite de précise de ta
part, les fichiers que tu manipuleras et créeras également. Ça permet bien
de parler de natif, je trouve.

À (at) 16 Dec 2008 11:37:20 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):

Paul Gaborit wrote in message <wt93ago8nvo.fsf@marceau.enstimac.fr>:

Mais c'est un encodage par défaut (c'est à dire en l'absence de
réglage plus spécifique). Aucun soft système n'exige le choix d'un
encodage spécifique à ce niveau pour fonctionner

Bien sûr. C'est pour ça que je l'évoque pour l'encodage « natif » de la
machine, pas de l'encodage « obligatoire ». Le fait est que, quand tu
débarques sur une machine, l'immense majorité des fichiers texte seront dans
l'encodage indiqué ici, et sauf manipulation explicite de précise de ta
part, les fichiers que tu manipuleras et créeras également. Ça permet bien
de parler de natif, je trouve.

C'est donc bien un problème de vocabulaire. Pour moi, le codage dont
tu parles est le codage par défaut pour les (softs) utilisateurs. Ça
ne correspond pas à ce que j'appellerai le codage natif du système.

Ensuite, au vu de cette discussion et du temps qu'on a mis à se
comprendre, je suis d'accord avec toi pour dire que le terme "encodage
natif" choisi par la documentation Perl n'est pas vraiment adapté. Il
laisse supposé que le "natif" se rapporte au système alors qu'il se
rapporte à perl tel qu'il est implémenté sur l'OS et l'architecture
courante (avec en plus le poids de l'histoire). Sur le moment, cela ne
m'avait pas choqué car je l'avais tout de suite pris dans le bon
sens. Mais en fait, c'est réellement ambigu.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

merci pour ta reponse, je la guettais avec impatience, et je criais
deja sur un canal #perl :

"ca y est ! ca y est ! j'ai reussi a coller paul gaborit ! il repond
rien !"

...mais je constate qu'il n'est pas ne celui qui te collera. par
contre, je n'ai pas eu le temps de suivre le reste de la discussion,
ma connexion a saute, je poste depuis la planete pluton la...

---

luc2