Discussion :

[imer5]

Bonjour,

J'explique rapidement la situation, je suis confronté à deux types de personnes, les utilisateurs qui ne veulent pas les caractères accentués soient supprimés (je suis assez d'accord), et un sois disant informaticien qui veut tous les supprimer parce que PHP transorfme par exemple le "é" en &.#.2.3.3.;. (y trouve ça pas bien) Pourtant je trouve que php et PG communique bien, qu'il faut juste faire attention aux apostrophes. J'arrive pas à trouver les arguments pour le dissuader de garder ces accents, a t il raison (ce sont des données brutes, ça ne concerne pas de clés primaire ou etrangere)?

Et dans le cas ou l'on souhaiterait exporter les données de PG dans des fichiers standard, on retrouverait cette codification de caratère, existe t il des fonctions pour tansformer le &.#.2.3.3.;. en "é" (to_ascii?)

Merci

[GrandFather]

Bonjour,

quelque chose m'échappe, ça veut dire quoi transformer le é en "é" ?

[imer5]

arrrrfffff j'ai pas relu, c'est le forum qui a transformer le code en é justement.

Dans PG (et on le vois via ce forum), le caractère "é" est enregistré comme suit &.#.2.3.3;. (sans les points)

J'espère avoir été plus clair désolé

[kryskool]

Il semblerait qu'en fait ce soit la valeur de l'entité HTML qui est enregistré

il suffit d'utiliser la fonction html_entity_decode avant d'insérer les datas dans la base

[imer5]

Merci pour ta réponse mais il semblerait que la transformation des caracteres se fasse directement dans PG.

Je m'explique, j'utilise phpPgAdmin et si j'édite les datas directement dans PG, c'est à ce moment la qu'il insére ces caractères spéciaux. Si j'utilise PgAdminIII, il n'y a pas de conversion de caractères.

Et si j'insère directement avec mon application, il n'y a pas de problème. Je sais c'est un problème stupide puisqu'il suffit de pas toucher à la base directement mais on me casse les pieds pour qu'il n'y ait pas ces caractères! Si vous avez des arguments la dessus