Bonjour,
 
En fait quand je récupère mes variables après un POST, tous mes accents se transforment !
Par exemple un é se transforme en xé. Enfin quand je fait un echo à l'écran, ça s'affiche normalement, mais par exemple si je met cette valeur dans une base de donnée, ou si je renomme un fichier avec cette valeur, je me retrouve avec le xé par exemple, au lieu du é voulu...
 
Je vois pas d'où ça vient.. de la configuration de php ? Je sais pas du tout.
 
Merci de votre aide !

de la configuration de la base, de l'editeur utilisé pour faire tes pages php (l'encodage choisis), de l'encodage choisis dans les pages html/php

Ta page HTML a-t-elle bien un encodage quelqconque ?
Si oui, c'est quoi l'encodage de ta page HTML ?
 
edit : rohhh, grilled !

Je suis en UTF8 pour mes documents. La valeur avec laquelle j'ai un problème provient d'un formulaire, dont la FORM est en enctype="multipart/form-data". Je me demande si ça vient pas de ça, mais j'en ai besoin car avec ce formulaire on peut aussi envoyer un fichier...

http://forum.hardware.fr/hardwaref [...] 7927-1.htm
Y-a-t-il un élément de réponse dans ce topic?

excuses moi je n'avais pas bien lu ...
donc j'aurais pu en déduire que tes pages étaient OK ...
c'est (ça doit) donc un problème de conversion au niveau de la DB
essaye cette requête 'SET NAMES utf8', une seule fois, juste après la cnx au serveur
sous entendu que tes tables sont bien en utf8_general_ci ou autres utf8, sinon tu devras faire un CONVERT USING, tout ça sous entendu que tu as par ex. un serv. mysql 4+

Le problème c'est que je connais tout ça, j'utilise déjà utf8_encode et utf8_decode à tour de bras mais... là... j'ai beau faire du decode... de toute façon c'est pas de l'UTF8... J'avoue je bloque vraiment vraiment là...

bah lors dans ce cas je puis juste te dire que le enctype="multipart/form-data" est hors de cause, vu que j'en ai qlqs uns des commes çà, qui tourne bien en UTF8 ... mais c'est forcément de l'UTF8, si tu l'affiches bien à l'écran via une page HTML en UTF8 !?! nan ?

C'est très clair ton problème ...
 
Apparement, ton éditeur fait du code en utf8. Les pages que tu affiches sont en quel encodage ? Qu'est-ce que te dis ton navigateur si tu affiches les propriétés de la page ?
Au niveau de ta base de données, tu utilises quoi ? (nom du serveur de BD + encodage/collation de ta base)
 
Le enctype n'a rien à voir la dedans.

Je n'ai pas vraiment d'éditeur, j'utilise UltraEdit, mais mes .php sont enregistrés en UTF-8, enfin bref ça n'a pas vraiment de rapport avec le code qui est généré.
 
Les pages que je génère sont en UTF-8, et on retrouve bien cet information dans les "Informations de la page" dans Firefox.
 
Dans ma base de données (qui est en SQLite), j'ai déjà beaucoup d'informations, des articles et d'autres trucs, tous encodés via utf8_encode() à la sortie de la base de données pour être affichées correctement. Jusque là aucun problème.
 
Là, c'est ce formulaire qui me pose problème avec method="post", et enctype="multipart/form-data".  Bon en fait c'est le premier formulaire que je fais sur ce site Les informations que j'ai déjà dans ma base de données je les ai mis à la main.
 
Bref, après ce formulaire, quand j'affiche les informations que j'ai rentré directement sur le site, aucun problème, je retrouve bien mes accents. Par contre, je renomme un fichier selon une des entrées du formulaire. Et ci-celle ci possède un accent, blam, je me retrouve avec un nom de fichier zigouillé de la forme dxédxé par exemple... Pareil si je l'inclus dans la base de données...

Bon la solution est vraiment très idiote...
Il suffit de faire un utf8_decode() sur les valeurs que j'ai récupéré et je retrouve mes accents !

Normalement, SQLite supporte les données utf-8, tu devrais pas avoir besoin d'encoder tes données avant de les mettres dedans ...
 
Si tes scripts sont en utf-8, ta base en utf-8, et que ton serveur envoi bien un Content-Encoding utf-8, tu devrais pas avoir besoin d'utiliser les fonctions utf8_encode et _decode (à moins que tu veuilles double travail/emploi). La, typiquement, tu te fais chier pour rien, et tu risques fort de te retrouver avec des données doublement encodé (tu peux faire un essai d'ailleurs en faisant un double décodage : utf8_decode(utf8_decode($toto)); )
 
Pour le nom du fichier, si c'est pas du au fait que tu sur-utilises les fonctions utf8_, regarde éventuellement au niveau du système de fichiers utilisés sur la machine (si tu y as accès), bien que ça devrait pas poser ce genre de problèmes.

Ouais, donc, cf. plus haut.

Oui tu as parfaitement raison, en fait je test avec un serveur IIS donc j'imagine que pour le renommage des fichiers c'est de l'ISO français, et pour la base de données... à mon avis par défaut elle doit se caler sur l'encodage système donc... pareil l'ISO français une fois de plus, d'où l'utilité du decode...  
 
Par contre si on va sur un système unix comment ça va réagir ? Ohla, j'ai pas eu l'occasion de tester. Ca me semble prise de tête ces histoires d'encodage !

Pour la base de données, SQLite gèere tout en unicode ("TEXT. The value is a text string, stored using the database encoding (UTF-8, UTF-16BE or UTF-16-LE).", http://www.sqlite.org/datatype3.html )
 
Pour le nom des fichiers, c'est un peu bancale. Au pire, il te les enregistrera avec des noms déformés, et quand tu les liras (en utf-8), tu récupereras automatiquement les bons noms. Faut essayer.
 
Eventuellement, suivant comment sont fait tes scripts, tu peux avoir deux fonctions pour enregistrer et charger tes fichiers, qui prennent un nom de fichier en utf-8 et qui le converti en iso avant de lire ou d'écrire dans le fichier.
 
Mais évite d'utiliser à tord et a travers les fonctions utf8_, surtout si tout est déjà en utf8_, c'est un coup à faire des trucs en doubles, et à chercher _longtemps_ d'où ça vient (expérience inside).