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

problème utf-8 (besoin de confirmation)

5 réponses
Avatar
paul POULAIN
Bonjour,

Je reviens vers vous avec mes problèmes utf-8...
Après recherche et investigation j'ai l'impression que j'ai trouvé l'origine
du problème :
* je traite de l'utf-8 de bout en bout
* je termine en faisant un print vers le STDOUT. Le flux est un flux http,
avec les headers utf-8 kivonbien.

Sauf que la page dans mozilla s'affichait mal : es caractères accentués
apparaissaient comme des "," et si on forçait le iso8859-1 dans le
navigateur, on récupérait bien les "é".
Conclusion : entre le "print" et le navigateur, qqc se passait !

J'ai essayé de mettre un "vrai" caractère utf-8, le "smiley" (\x{263a})
et oh surprise : la page apparaissait correctement, les é étaient bien des é
en utf-8 (ce que j'ai confirmé en forçant l'iso8859-1, qui m'a fait des pas
jolis trucs à la place)

Damned, quelqu'un a donc changé quelque chose !!!

Heureusement, perldoc perluniintro a été mon ami :
> For example,
> perl -e 'print "\x{DF}\n", "\x{0100}\x{DF}\n"'
> produces a fairly useless mixture of native bytes and UTF-8, as well as a
> warning:
> Wide character in print at ...
> To output UTF-8, use the ":utf8" output layer. Prepending
> binmode(STDOUT, ":utf8");
> to this sample program ensures that the output is completely UTF-8, and
> removes the program's warning.

Je rajoute le binmode... et... CA MARCHE !!!
Ca alors ! dois-je en conclure que Perl s'est cru plus intelligent que moi
et a transformé mon utf-8 en iso8859-1 avant de faire le "print" ?
Une autre explication ? (genre : ca marche, mais c'est le hasard, la vraie
raison est ailleurs)

Merci de vos lumières...
--
Paul

5 réponses

Avatar
Nicolas George
paul POULAIN wrote in message <dsvfc2$12u1$:
Ca alors ! dois-je en conclure que Perl s'est cru plus intelligent que moi
et a transformé mon utf-8 en iso8859-1 avant de faire le "print" ?


C'est un peu ça. Ce n'est pas vraiment une question de se croire plus
intelligent, mais d'assurer la compatibilité avec les anciennes versions.
D'une manière générale, quand on travaille avec du texte au delà d'ASCII, il
est important de bien déclarer le comportement partout où ce texte entre
sous le contrôle de Perl ou en sort : lectures de fichiers (binmode), code
source du programme (use utf8), et éventuellement bibliothèques tierces
foireuses (decode/encode).

Avatar
paul POULAIN
Nicolas George wrote:

paul POULAIN wrote in message <dsvfc2$12u1$:
Ca alors ! dois-je en conclure que Perl s'est cru plus intelligent que
moi et a transformé mon utf-8 en iso8859-1 avant de faire le "print" ?


C'est un peu ça. Ce n'est pas vraiment une question de se croire plus
intelligent, mais d'assurer la compatibilité avec les anciennes versions.
D'une manière générale, quand on travaille avec du texte au delà d'ASCII,
il est important de bien déclarer le comportement partout où ce texte
entre sous le contrôle de Perl ou en sort : lectures de fichiers
(binmode), code source du programme (use utf8), et éventuellement
bibliothèques tierces foireuses (decode/encode).


D'accord, l'explication est convaincante. C'est juste que quand on ne sait
pas, on est bien troublé. Mais maintenant je suis "aware".
Sauf pour mySQL : mes tables mySQL sont en "unicode_general_ci", mais j'ai
toujours des problèmes.
Y aurait il là encore un truc de compatibilité mySQL/Perl/utf-8 ?
--
Paul


Avatar
Nicolas George
paul POULAIN wrote in message <dsvi6f$1415$:
Sauf pour mySQL : mes tables mySQL sont en "unicode_general_ci", mais j'ai
toujours des problèmes.
Y aurait il là encore un truc de compatibilité mySQL/Perl/utf-8 ?


Je ne connais pas du tout MySQL, et encore moins son interface avec Perl. Je
peux quand même donner une méthode de diagnostique. D'abord, il faut stocker
dans MySQL, par un moyen fiable, une valeur contenant des caractères
non-latin-1. Disons le mot « coeur », mais avec un vrai oe. Ensuite, écrire
un programme Perl élémentaire qui va chercher cette valeur. Disons qu'elle
se retrouve dans $test :

for (split "", $test) {
print ord, "n";
}

Deux versions sont possibles :

99
197
147
117
114

ou

99
339
117
114

Dans le second cas, c'est bon, on sait que la bibliothèque MySQL fait
correctement les choses. Dans le premier cas, ce n'est pas bon, et il faut
ajouter un appel à decode pour toutes les valeurs lues depuis la base de
données, et à encode pour toutes les valeurs qui y sont envoyées.

Avatar
paul POULAIN
Nicolas George wrote:

paul POULAIN wrote in message <dsvi6f$1415$:
Sauf pour mySQL : mes tables mySQL sont en "unicode_general_ci", mais
j'ai toujours des problèmes.
Y aurait il là encore un truc de compatibilité mySQL/Perl/utf-8 ?


Je ne connais pas du tout MySQL, et encore moins son interface avec Perl.
Je peux quand même donner une méthode de diagnostique. D'abord, il faut
stocker dans MySQL, par un moyen fiable, une valeur contenant des
caractères non-latin-1. Disons le mot « coeur », mais avec un vrai oe.
Ensuite, écrire un programme Perl élémentaire qui va chercher cette
valeur. Disons qu'elle se retrouve dans $test :


j'ai aussi cherché sur le ternet, et ce que j'ai trouvé me laisse
pessimiste :
http://www.cpanforum.com/threads/654
http://lists.mysql.com/perl/3714
http://marc.theaimsgroup.com/?l=msql-mysql-modules&m1970179409036&w=2
http://lists.mysql.com/perl/3006?f=plain
--
Paul


Avatar
Jacques Caron
Salut,

On Wed, 15 Feb 2006 16:43:06 +0100, paul POULAIN
wrote:

Sauf pour mySQL : mes tables mySQL sont en "unicode_general_ci", mais
j'ai toujours des problèmes.
Y aurait il là encore un truc de compatibilité mySQL/Perl/utf-8 ?


Je ne sais pas pour MySQL, mais pour PostreSQL, il y a un joli flag à
ajouter dans le connect:

$dbh =
DBI->connect("dbi:Pg:dbname=$dbname;host=$host;connect_timeout=5",$user,$pass,{pg_enable_utf8=>1});

Il y a peut-être l'équivalent dans DBI::Mysql. Le problème est que dans le
doute, perl ne peut pas savoir si ce qu'il reçoit est déjà de l'UTF-8 ou
pas. Sinon tu peux utiliser utf8::decode($variable) pour que perl se rende
compte que c'est déjà de l'UTF-8 et le reconnaisse comme tel.

Jacques.
--
Oxado http://www.oxado.com/