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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
heulman
"heulman" a écrit dans le message de news: 46ded917$0$25923$
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
"heulman" a écrit dans le message de news: 46ded917$0$25923$
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
Olivier Miakinen
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>.
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>.
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>.
heulman
"Olivier Miakinen" <om+ a écrit dans le message de news: 46e128a8$
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
"Olivier Miakinen" <om+ a écrit dans le message de news: 46e128a8$
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
$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.
$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.
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.
heulman
"Olivier Miakinen" <om+ a écrit dans le message de news: 46e6c286$
$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...
$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
"Olivier Miakinen" <om+ a écrit dans le message de news: 46e6c286$
$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
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 ?
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 ?
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 ?
