justement y'a pas que les accents , y'a tout les autre carateres aussi, en gros ca qu'on cherche a faire, c'est du simple et lisible pour tout le monde (a peu pret), et ecrivable (ca se dit pas) par tous aussi
donc le minium requis : l' ASCII
je peu tres bien mettre un caratere japonnais dans un nom de fichier, mais je vais pas m'amuser a tous les mettres dans ton str_replace
J'ai lu nul part que
thekingkong destinait son site à un public japonais...
Et donc concrètement selon ton système - lequel ? - il se passe quoi si un visiteur tente de télécharger un fichier image avec un nom qui comporte des caractères accentués, des espaces ou des caractères spéciaux ?
le caratere japonnais etant un exmple, et n'importe qui peu faire un caractère japonnais 映画、音楽,
par dessus tout ca, c'est soit un coup de url_encode, soit une conversion ascii moins les carateres non autoriser dans le nom d'un fichier (et les caratere qu'on veux en moins genre l'espace, un slash....)
en resumer url_encode ou iconv + preg
Ah on avance un peu puisque quelques post plus haut tu ne voyais pas de raison de remplacer les caractères accentués dans un fichier image.
1/ N'importe qui peut faire un caractère japonais, mais il est très peu probable que n'importe quel visiteur français ait un fichier image comportant un caractère japonais.
2/ On oublie url_encode dans ce cas particulier car on veut un fichier image lisible et accessible.
3/ Reste donc ta proposition d'utiliser iconv. Et proposer à un débutant d'utiliser iconv pour convertir les caractères accentués est pour le moins inadapté car c'est une usine à problème :
- D'une part pour faire des tests en local cela risque fort de retourner des résultats erronés.
- D'autre part, même sur le serveur distant cela risque de ne pas fonctionner correctement
cf ce post. Donc il est conseiller d'utiliser préalablement setlocale, et setlocale fonctionnera plus ou moins bien suivant la configuration du serveur
Niveau portabilité d'un script, on a déjà vu beaucoup mieux
Et puis l'avantage d'utiliser un srt_replace est que tu peux faire d'autres remplacements par la même occasion. Et même si tu ne couvre pas toutes les possibilités, tu auras fait l'essentiel et le preg qui suivra fera le reste du ménage. Ce qui reviendra presque au même que iconv mais avec des possibilités en plus et surtout sans avoir à se soucier de la configuration du serveur (chose essentielle pour la portabilité ou quand on donne des conseils sans savoir si la personne a la main sur le serveur ou non

)
@
thekingkong
Ah oui ton script est vieux effectivement car cela fait déjà longtemps qu'on utilise plus la syntaxe $HTTP_... (déprécié)
Donc déjà avec ton éditeur favori tu peux remplacer
$HTTP_GET_VARS par $_GET
$HTTP_SESSION_VARS par $_SESSION
$HTTP_POST_VARS par $_POST
Ensuite j'ai un doute sur le bien fondé d'utiliser utf-8 dans la bdd.
Je ne connais pas tous les éléments, mais si tu dois à un moment donné faire un include d'un fichier iso dans ton fichier utf-8, ou faire afficher des éléments de ta bdd codée en utf-8 dans un fichier iso, tu auras des problèmes.
Généralement quand on code en utf-8 on le fait dès le début sinon c'est risqué ou alors ça demande pas mal de travail pour convertir l'ensemble des scripts et finalement ce n'est généralement indispensable que si tu destine ton site à un public étranger avec des langues non latines.
Donc mon opinion est : codé en utf-8 est une bonne habitude pour les nouveaux scripts. Par contre pour les anciens (ou ceux inclus dans d'anciens scripts), la mise à jour ne doit se faire que si nécessaire.