Re: [sympa-fr] Migration 6.0.6 -> 6.1.1: l'encodage des shared docs revient à la charge...

[Benoit Branciard <adresse@cachée>]

Le 08/11/2010 12:08, David Verdin a écrit :
> Salut Benoît,
>
> Bon, décidément tu joues de malchance avec l'encodage !
> La conversion automatique lors de l'upgrade est - tu t'en doutes -
> censée éviter ce problème en uniformisant l'encodage. Rappel : tous nos
> problèmes venaient d'un changement dans la manière dont notre module
> CPAN gérait certains caractères en Q-encodant. Du coup, on remplace
> automatiquement les noms de fichier à problème lors de l'upgrade.
>
> Est-ce que tu as eu le problème sur de nombreux fichiers ?

Non, une centaine environ (122 pour être précis)

> Le 04/11/2010 21:52, Benoit Branciard a écrit :
> > En fait non, pas tout à fait... Ce que j'avais, c'était des fichiers
> > du type
> >
> > =?UTF-8?Q?Rapport_Arch=82ologie?=.doc
> >
> > (avec des caractères "=82", alors que le "é" en UTF8 Q-encodé donne
> > maintenant "=C3=A9" dans Sympa 6.1)
> En effet. Le caractère 82 n'est pas non plus très utile en latin 1 : il
> n'est pas imprimable. Bon, ce n'est pas forcément du latin 1.
> > Le rétablissement du nom d'origine rétablit l'accès au fichier, mais
> > dans wwsympa il apparait toujours sous le nom (Q-décodé) "Rapport
> > Arch\x82ologie.doc". Peut-être s'agissait-il de fichiers qui étaient
> > dans un mauvais encodage au moment du dépôt. J'ai aussi des "=FF" (?)
> > qui ont déclenché la conversion.
> "ÿ" en latin 1. Ça a le mérite de l'originalité.
> >

Je suspecte une cause à l'existence de ces fichiers bizarrement encodés: 
il pourrait s'agir de fichiers créés par upload et dézippage d'une 
archive .ZIP .

En effet zip/unzip sous Windows (une plate-forme client relativement 
courante) utilisent souvent l'encodage DOS (en général codepage 850 pour 
nous français), dans lequel \xFF est utilisé comme espace (équivalent au 
\x20), et \x82 est bien le "é".
Pour éviter le pb, je ne sais pas s'il y aurait un moyen automatique de 
détecter l'encodage utilisé dans un fichier ZIP au moment du dézippage 
côté serveur...

Pour en revenir au pb rencontré avec Sympa 6.1.1, ces noms de fichiers 
invalides (mais correctement Q-encodés, donc accessibles) ont déclenché 
une conversion, laquelle a recréé les mêmes noms, mais *non* Q-encodés, 
donc inaccessibles. Il y a donc 2 problèmes:
1) déclenchement d'une conversion inutile pour les noms de fichiers 
Q-encodés contenant des caractères non valides en UTF8;
2) absence de re-Q-encodage de ces noms de fichiers après conversion.


--
Benoit BRANCIARD

CRIR - SIS
Centre de Ressources Informatiques et du Réseau,
Service Infrastructures
http://crir.univ-paris1.fr
Université Paris 1 Panthéon-Sorbonne

Tel. 01 44 07 89 68

--
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.