Bonjour,

J'utilise l'extension PECL Zip sous php4 pour uploader des lots d'images.
Les répertoires sont transformés en albums et les noms de fichiers sont
utilisés comme titres pour les images (mais pas comme noms de fichiers).

Or zip_entry_name ne reconnait pas les caractères accentués, ce qui me donne
des noms d'albums et d'images peu lisibles.
J'ai essayé les quelques transformations qui me venait à l'esprit mais rien
ne marche.
Si ça peut aider:
è devient S
é devient ,

Y a-t-il un moyen de récupérer les noms corrects ?
Je ne veux pas utiliser une autre librairie, ni supprimer les caractères
spéciaux car j'en ai besoin.

merci,
heulman

"heulman" <heulman@hotmail.com> a écrit dans le message de news:
46ded917$0$25923$ba4acef3@news.orange.fr...
> J'utilise l'extension PECL Zip sous php4 pour uploader des lots d'images.
> Les répertoires sont transformés en albums et les noms de fichiers sont
> utilisés comme titres pour les images (mais pas comme noms de fichiers).

Pas très compréhensible mon truc, je recommence...

Dans mon zip j'ai un fichier "éléphant.jpg" situé dans le répertoire
"animaux".

Après décompression, j'obtiens un fichier "image-01.jpg" situé dans un
répertoire "album-01"
et j'ai les informations suivantes en base de données:
- "album-01" s'appelle "animaux"
- "image-01.jpg" a pour titre ",l,phant" <== là ça merdoit

> è devient S
> é devient ,

en fait è devient un s majuscule avec un accent circonflexe inversé ( S si
ce caractère veut bien passer)
si ça dit quelquechose à qq

> merci,
> heulman

ça c'est bon
heulman

"heulman" <heulman@hotmail.com> a écrit dans le message de news:
46ded917$0$25923$ba4acef3@news.orange.fr...
> J'utilise l'extension PECL Zip sous php4 pour uploader des lots d'images.
> Les répertoires sont transformés en albums et les noms de fichiers sont
> utilisés comme titres pour les images (mais pas comme noms de fichiers).

Pas très compréhensible mon truc, je recommence...

Dans mon zip j'ai un fichier "éléphant.jpg" situé dans le répertoire
"animaux".

Après décompression, j'obtiens un fichier "image-01.jpg" situé dans un
répertoire "album-01"
et j'ai les informations suivantes en base de données:
- "album-01" s'appelle "animaux"
- "image-01.jpg" a pour titre ",l,phant" <== là ça merdoit

> è devient S
> é devient ,

en fait è devient un s majuscule avec un accent circonflexe inversé ( S si
ce caractère veut bien passer)
si ça dit quelquechose à qq

> merci,
> heulman

ça c'est bon
heulman

Le 07/09/2007 09:51, heulman a écrit :
>
> Pas très compréhensible mon truc, je recommence...
>
> Dans mon zip j'ai un fichier "éléphant.jpg" situé dans le répertoire
> "animaux".
>
> Après décompression, j'obtiens un fichier "image-01.jpg" situé dans un
> répertoire "album-01"
> et j'ai les informations suivantes en base de données:
> - "album-01" s'appelle "animaux"
> - "image-01.jpg" a pour titre ",l,phant" <== là ça merdoit
>
>> è devient S
>> é devient ,
>
> en fait è devient un s majuscule avec un accent circonflexe inversé ( S si
> ce caractère veut bien passer)
> si ça dit quelquechose à qq

Je crois que j'ai trouvé. Attention, ma réponse est envoyée en CP1252
pour afficher les caractères en question.

Est-ce que ce qui suit est vrai ?
è devient ‚ (qui n'est pas une virgule « , » mais un guillemet anglais)
é devient Š (S avec caron)
à devient -- (trois points en un seul caractère)
ç devient ‡ (double-dagger)
ë devient ‰ (pour mille)

Si oui, c'est que tes noms de fichier sont écrits en CP850, jeu de
caractères par défaut des MS-DOS occidentaux, alors que les titres
attendent du CP1252, jeu de caractères par défaut des Windows
occidentaux (sauf probablement les plus récents qui doivent être
en UTF-8).

Pour trouver la correspondance entre les deux, va voir sur ma page
<http://www.miakinen.net/vrac/charsets/>, choisis un caractère dans
l'onglet CP850, et regarde lequel lui correspond dans l'onglet CP1252.

La solution en PHP, maintenant ? Tu peux utiliser iconv pour convertir
de CP850 vers CP1252. Voir <http://fr2.php.net/iconv>.

Le 07/09/2007 09:51, heulman a écrit :
>
> Pas très compréhensible mon truc, je recommence...
>
> Dans mon zip j'ai un fichier "éléphant.jpg" situé dans le répertoire
> "animaux".
>
> Après décompression, j'obtiens un fichier "image-01.jpg" situé dans un
> répertoire "album-01"
> et j'ai les informations suivantes en base de données:
> - "album-01" s'appelle "animaux"
> - "image-01.jpg" a pour titre ",l,phant" <== là ça merdoit
>
>> è devient S
>> é devient ,
>
> en fait è devient un s majuscule avec un accent circonflexe inversé ( S si
> ce caractère veut bien passer)
> si ça dit quelquechose à qq

Je crois que j'ai trouvé. Attention, ma réponse est envoyée en CP1252
pour afficher les caractères en question.

Est-ce que ce qui suit est vrai ?
è devient ‚ (qui n'est pas une virgule « , » mais un guillemet anglais)
é devient Š (S avec caron)
à devient -- (trois points en un seul caractère)
ç devient ‡ (double-dagger)
ë devient ‰ (pour mille)

Si oui, c'est que tes noms de fichier sont écrits en CP850, jeu de
caractères par défaut des MS-DOS occidentaux, alors que les titres
attendent du CP1252, jeu de caractères par défaut des Windows
occidentaux (sauf probablement les plus récents qui doivent être
en UTF-8).

Pour trouver la correspondance entre les deux, va voir sur ma page
<http://www.miakinen.net/vrac/charsets/>, choisis un caractère dans
l'onglet CP850, et regarde lequel lui correspond dans l'onglet CP1252.

La solution en PHP, maintenant ? Tu peux utiliser iconv pour convertir
de CP850 vers CP1252. Voir <http://fr2.php.net/iconv>.

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46e128a8$1@neottia.net...
> Est-ce que ce qui suit est vrai ?
> è devient ‚ (qui n'est pas une virgule « , » mais un guillemet anglais)
> é devient Š (S avec caron)
> à devient -- (trois points en un seul caractère)
> ç devient ‡ (double-dagger)
> ë devient ‰ (pour mille)

Tout bon

> Si oui, c'est que tes noms de fichier sont écrits en CP850, jeu de
> caractères par défaut des MS-DOS occidentaux, alors que les titres
> attendent du CP1252, jeu de caractères par défaut des Windows
> occidentaux (sauf probablement les plus récents qui doivent être
> en UTF-8).

> La solution en PHP, maintenant ? Tu peux utiliser iconv pour convertir
> de CP850 vers CP1252. Voir <http://fr2.php.net/iconv>.

$k = iconv("CP850", "CP1252", $j);

Effectivement, ça roule ! ... enfin presque.

Avec 7-zip ou WinRar ça fonctionne, mais pas tout à fait avec WinZip.
En effet, quand WinZip trouve un oe ("e dans l'o") dans le nom de fichier il
semble qu'il utilise CP1252 (ou autre chose mais pas CP850), du coup de
décodage ne fonctionne pas et on obtient n'importe quoi.
Mais dans le même fichier Zip, d'autres fichiers accentués sans oe sont bien
écrits en CP850.

Le problème est le même sans passer par php, par exemple en zippant depuis
Winzip et en dézippant avec 7-zip.

J'avoue être complètement à l'ouest avec tous ces pbs d'encodage.
Est-ce qu'il y a un moyen de vérifier le jeu de caractère utilisé pour
déterminer si il faut le changer ?
Je ne vois rien ni dans iconv, ni dans php_zip.

En tout cas merci pour cette réponse précise,
Heulman

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46e128a8$1@neottia.net...
> Est-ce que ce qui suit est vrai ?
> è devient ‚ (qui n'est pas une virgule « , » mais un guillemet anglais)
> é devient Š (S avec caron)
> à devient -- (trois points en un seul caractère)
> ç devient ‡ (double-dagger)
> ë devient ‰ (pour mille)

Tout bon

> Si oui, c'est que tes noms de fichier sont écrits en CP850, jeu de
> caractères par défaut des MS-DOS occidentaux, alors que les titres
> attendent du CP1252, jeu de caractères par défaut des Windows
> occidentaux (sauf probablement les plus récents qui doivent être
> en UTF-8).

> La solution en PHP, maintenant ? Tu peux utiliser iconv pour convertir
> de CP850 vers CP1252. Voir <http://fr2.php.net/iconv>.

$k = iconv("CP850", "CP1252", $j);

Effectivement, ça roule ! ... enfin presque.

Avec 7-zip ou WinRar ça fonctionne, mais pas tout à fait avec WinZip.
En effet, quand WinZip trouve un oe ("e dans l'o") dans le nom de fichier il
semble qu'il utilise CP1252 (ou autre chose mais pas CP850), du coup de
décodage ne fonctionne pas et on obtient n'importe quoi.
Mais dans le même fichier Zip, d'autres fichiers accentués sans oe sont bien
écrits en CP850.

Le problème est le même sans passer par php, par exemple en zippant depuis
Winzip et en dézippant avec 7-zip.

J'avoue être complètement à l'ouest avec tous ces pbs d'encodage.
Est-ce qu'il y a un moyen de vérifier le jeu de caractère utilisé pour
déterminer si il faut le changer ?
Je ne vois rien ni dans iconv, ni dans php_zip.

En tout cas merci pour cette réponse précise,
Heulman

Le 10/09/2007 23:17, heulman a écrit :
>
> $k = iconv("CP850", "CP1252", $j);
>
> Effectivement, ça roule ! ... enfin presque.
>
> Avec 7-zip ou WinRar ça fonctionne, mais pas tout à fait avec WinZip.
> En effet, quand WinZip trouve un oe ("e dans l'o") dans le nom de fichier

Ah ? Parce que 7-zip et WinRar n'ont *pas* de problème pour encoder un ½
en CP850 ? Ben comment ils font, alors, vu que ce caractère n'existe pas
dans cette table ?

C'est une vraie question, et j'aimerais bien savoir ce qu'ils en font
(par exemple une « translittération » en oe).

> il semble qu'il utilise CP1252 (ou autre chose mais pas CP850), du coup de
> décodage ne fonctionne pas et on obtient n'importe quoi.

Si tu veux que je puisse t'aider il faudrait que je sache ce que devient
ce ½ dans WinZip, avant que tu ne le transformes par iconv.

> [...]
>
> J'avoue être complètement à l'ouest avec tous ces pbs d'encodage.

C'est un problème difficile à cause de tous ces endroits où on a un jeu
de caractères non déclaré, mais avec de la patience ça peut finir par
devenir amusant.

> Est-ce qu'il y a un moyen de vérifier le jeu de caractère utilisé pour
> déterminer si il faut le changer ?

Ça c'est un problème encore plus difficile à traiter dans toute sa
généralité : il faut connaître des indicateurs spécifiques non seulement
aux jeux de caractères, mais aussi aux langues (français, polonais,
arabe, chinois, etc.). UTF-8 est un cas particulier, car il est
généralement facile de prouver qu'un texte n'est *pas* en UTF-8.

Dans le cas particulier où tu n'aurais que CP1252 et CP850 à l'exclusion
de tout autre, et que du français, il y a quelques tests assez simples
qui devraient fonctionner la plupart du temps. Par exemple, les
minuscules accentuées du français sont toutes dans 0x9C ou 0xE0..0xFF
pour la table CP1252, alors qu'elles sont toutes dans 0x81..0x98 pour
CP850. Ainsi, compter le nombre de caractères dans chaque zone (avant
d'appeler iconv(), mais peut-être aussi après pour vérifier) peut te
donner un indice assez pertinent. Il peut être utile d'y rajouter les
majuscules accentuées, mais avec un poids moins important : surtout les
trois caractères Ç, É et À qui se retrouvent plus facilement en début
de phrases.

Le 10/09/2007 23:17, heulman a écrit :
>
> $k = iconv("CP850", "CP1252", $j);
>
> Effectivement, ça roule ! ... enfin presque.
>
> Avec 7-zip ou WinRar ça fonctionne, mais pas tout à fait avec WinZip.
> En effet, quand WinZip trouve un oe ("e dans l'o") dans le nom de fichier

Ah ? Parce que 7-zip et WinRar n'ont *pas* de problème pour encoder un ½
en CP850 ? Ben comment ils font, alors, vu que ce caractère n'existe pas
dans cette table ?

C'est une vraie question, et j'aimerais bien savoir ce qu'ils en font
(par exemple une « translittération » en oe).

> il semble qu'il utilise CP1252 (ou autre chose mais pas CP850), du coup de
> décodage ne fonctionne pas et on obtient n'importe quoi.

Si tu veux que je puisse t'aider il faudrait que je sache ce que devient
ce ½ dans WinZip, avant que tu ne le transformes par iconv.

> [...]
>
> J'avoue être complètement à l'ouest avec tous ces pbs d'encodage.

C'est un problème difficile à cause de tous ces endroits où on a un jeu
de caractères non déclaré, mais avec de la patience ça peut finir par
devenir amusant.

> Est-ce qu'il y a un moyen de vérifier le jeu de caractère utilisé pour
> déterminer si il faut le changer ?

Ça c'est un problème encore plus difficile à traiter dans toute sa
généralité : il faut connaître des indicateurs spécifiques non seulement
aux jeux de caractères, mais aussi aux langues (français, polonais,
arabe, chinois, etc.). UTF-8 est un cas particulier, car il est
généralement facile de prouver qu'un texte n'est *pas* en UTF-8.

Dans le cas particulier où tu n'aurais que CP1252 et CP850 à l'exclusion
de tout autre, et que du français, il y a quelques tests assez simples
qui devraient fonctionner la plupart du temps. Par exemple, les
minuscules accentuées du français sont toutes dans 0x9C ou 0xE0..0xFF
pour la table CP1252, alors qu'elles sont toutes dans 0x81..0x98 pour
CP850. Ainsi, compter le nombre de caractères dans chaque zone (avant
d'appeler iconv(), mais peut-être aussi après pour vérifier) peut te
donner un indice assez pertinent. Il peut être utile d'y rajouter les
majuscules accentuées, mais avec un poids moins important : surtout les
trois caractères Ç, É et À qui se retrouvent plus facilement en début
de phrases.

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46e6c286$1@neottia.net...
> Le 10/09/2007 23:17, heulman a écrit :
>>
>> $k = iconv("CP850", "CP1252", $j);
>>
>> Effectivement, ça roule ! ... enfin presque.
>>
>> Avec 7-zip ou WinRar ça fonctionne, mais pas tout à fait avec WinZip.
>> En effet, quand WinZip trouve un oe ("e dans l'o") dans le nom de fichier
>
> Ah ? Parce que 7-zip et WinRar n'ont *pas* de problème pour encoder un ½
> en CP850 ? Ben comment ils font, alors, vu que ce caractère n'existe pas
> dans cette table ?
> C'est une vraie question, et j'aimerais bien savoir ce qu'ils en font
> (par exemple une « translittération » en oe).

7-zip et WinRar utilisent CP850 donc le ½ devient o, mais au moins ils
utilisent *toujours* CP850

>> Est-ce qu'il y a un moyen de vérifier le jeu de caractère utilisé pour
>> déterminer si il faut le changer ?
>
> Ça c'est un problème encore plus difficile à traiter dans toute sa
> généralité : il faut connaître des indicateurs spécifiques non seulement
> aux jeux de caractères, mais aussi aux langues (français, polonais,
> arabe, chinois, etc.). UTF-8 est un cas particulier, car il est
> généralement facile de prouver qu'un texte n'est *pas* en UTF-8.
>
> Dans le cas particulier où tu n'aurais que CP1252 et CP850 à l'exclusion
> de tout autre, et que du français, il y a quelques tests assez simples
> qui devraient fonctionner la plupart du temps. Par exemple, les
> minuscules accentuées du français sont toutes dans 0x9C ou 0xE0..0xFF
> pour la table CP1252, alors qu'elles sont toutes dans 0x81..0x98 pour
> CP850. Ainsi, compter le nombre de caractères dans chaque zone (avant
> d'appeler iconv(), mais peut-être aussi après pour vérifier) peut te
> donner un indice assez pertinent. Il peut être utile d'y rajouter les
> majuscules accentuées, mais avec un poids moins important : surtout les
> trois caractères Ç, É et À qui se retrouvent plus facilement en début
> de phrases.

pffouillouillouille, trop compliqué pour moi
je pense en rester là, et tant pis si les utilisateurs utilisent ½ ET Winzip

merci pour tout,
heulman

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46e6c286$1@neottia.net...
> Le 10/09/2007 23:17, heulman a écrit :
>>
>> $k = iconv("CP850", "CP1252", $j);
>>
>> Effectivement, ça roule ! ... enfin presque.
>>
>> Avec 7-zip ou WinRar ça fonctionne, mais pas tout à fait avec WinZip.
>> En effet, quand WinZip trouve un oe ("e dans l'o") dans le nom de fichier
>
> Ah ? Parce que 7-zip et WinRar n'ont *pas* de problème pour encoder un ½
> en CP850 ? Ben comment ils font, alors, vu que ce caractère n'existe pas
> dans cette table ?
> C'est une vraie question, et j'aimerais bien savoir ce qu'ils en font
> (par exemple une « translittération » en oe).

7-zip et WinRar utilisent CP850 donc le ½ devient o, mais au moins ils
utilisent *toujours* CP850

>> Est-ce qu'il y a un moyen de vérifier le jeu de caractère utilisé pour
>> déterminer si il faut le changer ?
>
> Ça c'est un problème encore plus difficile à traiter dans toute sa
> généralité : il faut connaître des indicateurs spécifiques non seulement
> aux jeux de caractères, mais aussi aux langues (français, polonais,
> arabe, chinois, etc.). UTF-8 est un cas particulier, car il est
> généralement facile de prouver qu'un texte n'est *pas* en UTF-8.
>
> Dans le cas particulier où tu n'aurais que CP1252 et CP850 à l'exclusion
> de tout autre, et que du français, il y a quelques tests assez simples
> qui devraient fonctionner la plupart du temps. Par exemple, les
> minuscules accentuées du français sont toutes dans 0x9C ou 0xE0..0xFF
> pour la table CP1252, alors qu'elles sont toutes dans 0x81..0x98 pour
> CP850. Ainsi, compter le nombre de caractères dans chaque zone (avant
> d'appeler iconv(), mais peut-être aussi après pour vérifier) peut te
> donner un indice assez pertinent. Il peut être utile d'y rajouter les
> majuscules accentuées, mais avec un poids moins important : surtout les
> trois caractères Ç, É et À qui se retrouvent plus facilement en début
> de phrases.

pffouillouillouille, trop compliqué pour moi
je pense en rester là, et tant pis si les utilisateurs utilisent ½ ET Winzip

merci pour tout,
heulman

Le 13/09/2007 10:26, heulman a écrit :
>
> 7-zip et WinRar utilisent CP850 donc le ½ devient o, mais au moins ils
> utilisent *toujours* CP850

Ah, d'accord. Donc on est dans le cas simple où il n'y a que deux
jeux possibles, qui plus est l'un des deux n'étant conservé que si un
caractère inconnu a été trouvé (donc le caractère ½ pour quelqu'un qui
n'utilise pas d'autres diacritiques que les minuscules du français).

>> [...]
>
> pffouillouillouille, trop compliqué pour moi
> je pense en rester là, et tant pis si les utilisateurs utilisent ½ ET Winzip

Allez, tu veux un mini code pour traiter le cas du « ½ » tout seul ?

$oe_en_cp1252 = chr(156);
if (strpos($j, $oe_en_cp1252) === false) {
$k = iconv("CP850", "CP1252", $j);
} else {
$k = $j;
}

Le 13/09/2007 10:26, heulman a écrit :
>
> 7-zip et WinRar utilisent CP850 donc le ½ devient o, mais au moins ils
> utilisent *toujours* CP850

Ah, d'accord. Donc on est dans le cas simple où il n'y a que deux
jeux possibles, qui plus est l'un des deux n'étant conservé que si un
caractère inconnu a été trouvé (donc le caractère ½ pour quelqu'un qui
n'utilise pas d'autres diacritiques que les minuscules du français).

>> [...]
>
> pffouillouillouille, trop compliqué pour moi
> je pense en rester là, et tant pis si les utilisateurs utilisent ½ ET Winzip

Allez, tu veux un mini code pour traiter le cas du « ½ » tout seul ?

$oe_en_cp1252 = chr(156);
if (strpos($j, $oe_en_cp1252) === false) {
$k = iconv("CP850", "CP1252", $j);
} else {
$k = $j;
}