Passage à PHP5.6, problème sur caractères accentués

WRInaute accro
Bonjour,

Je migre mon site vers PHP5.6 en ce moment (actuellement, j'ai du PHP4).
Comme je suis chez OVH, je modifie le fichier .ovhconfig.
Mais alors mes caractères accentués sont mal affichés.
J'ai changé ma balise charset vers la syntaxe HTML5 pour voir, en vain.

Savez-vous me dire ce qui se passe ?

Merci d'avance,

OTP
 
WRInaute accro
Ça vient de :
- Encoding des fichiers PHP
- Headers HTTP
- Meta charset
- Database / columns
 
WRInaute accro
Heu, merci, mais...

- Encoding des fichiers PHP : les fichiers non executés ?
- Headers HTTP : la syntaxe est à changer ?
- Meta charset : la syntaxe est à changer ?
- Database / columns : mysql ? Le souci est aussi sur le texte non issu des tables

OTP
 
WRInaute accro
OTP a dit:
- Encoding des fichiers PHP : les fichiers non executés ?
Tous les fichiers parsés.
OTP a dit:
- Headers HTTP : la syntaxe est à changer ?
Juste vérifier qu'il n'y a pas de AddDefaultCharset différent de celui voulu
OTP a dit:
- Meta charset : la syntaxe est à changer ?
Mettre celui correspondant à ton doctype. (différent en HTML5/XHTML)
OTP a dit:
- Database / columns : mysql ? Le souci est aussi sur le texte non issu des tables
Donc ça vient pas de là
 
WRInaute accro
toujours écrire et stocker en base les caractères accentués de cette façon :

é = & e a c u t e ;

Ainsi, même en changeant l'encodage dans le navigateur (firefox permet de changer facilement), les caractères particuliers restent les mêmes et ne sont pas remplacés par des codes graphiques
 
WRInaute impliqué
indigene a dit:
toujours écrire et stocker en base les caractères accentués de cette façon :

é = & e a c u t e ;

Ainsi, même en changeant l'encodage dans le navigateur (firefox permet de changer facilement), les caractères particuliers restent les mêmes et ne sont pas remplacés par des codes graphiques

N'importe quoi. Rien de tel pour pourrir une base de données …
Les données mise en base doivent être comme elles ont été fournies. Les traitements liés à un contexte ne doivent pas y apparaître. Ceci permet une bonne interopérabilité des données.

Depuis PHP 5.6, le charset par défaut est l'UTF-8.
Il faut donc examiner l'existant pour savoir si tu souhaites passer complètement à UTF-8 ou en ISO.
Si ton existant est en ISO, tu peux configurer ce paramètre pour passer de UTF-8 à l'ISO.
 
WRInaute accro
Encoding des fichiers PHP : les fichiers non executés ?
Tous les fichiers parsés.

C'est à dire il faut faire quoi .

Headers HTTP : la syntaxe est à changer ?
Juste vérifier qu'il n'y a pas de AddDefaultCharset différent de celui voulu

Dans le header j'imagine ? Rien trouvé de tel

Meta charset : la syntaxe est à changer ?
Mettre celui correspondant à ton doctype. (différent en HTML5/XHTML)

Je n'ai pas changé le doctype. Ca fonctionnait bien avant.

Database / columns : mysql ? Le souci est aussi sur le texte non issu des tables
Donc ça vient pas de là

C'est déjà ça ! :)
 
WRInaute accro
indigene a dit:
Pas si on est en Latin-1 (ISO 8859-1). Le addslashes est suffisant (confirmé plus bas dans le même article)

Suffisant ou non le addslashes n'est pas propre tu stockes un / en plus dans ta bdd et tu es obligé de faire un stripslashes à la sortie. le addslashes était utilisé lorsqu'il y avait le magic quotes d'activé il me semble. ce n’est plus le cas avec les nouvelles versions de php.

De plus avec la fonction mysql_real_escape_string() ça gère les injections sans soucis et sans pourrir ta bdd ni besoin d'utiliser stripslashes. Et il me semble que mysql_real_escape_string() protège plus de caracteres.

J'utilisais les addslashes sur de vieux sites, mais il y a quelques mois j'ai remplacé par mysqli_real_escape_string() et nettoyé ma bdd des / en trop. Bien plus propre.
 
WRInaute accro
Bien, je vois que j'ai du pain sur la planche. Il faudra que je me forme à ces nouvelles technologies. Je dois toujours coder en php 3 avec les adaptations nécessaire pour que ça passe en php 5.
En fait mon code n'a pas évolué depuis 2003-2006 :lol:
Mais comme je dois coder une ou deux fois par an c'est pas trop un soucis non plus.
 
WRInaute accro
indigene a dit:
En fait mon code n'a pas évolué depuis 2003-2006 :lol:
Mais comme je dois coder une ou deux fois par an c'est pas trop un soucis non plus.

Pareil pour moi sauf que j'ai un ultimatum d'OVH à fin septembre... :(
 
WRInaute accro
OTP a dit:
Pareil pour moi sauf que j'ai un ultimatum d'OVH à fin septembre... :(

ultimatum d'OVH pour septembre
ultimatum de Google pour 21 avril 2015

J'ai commencé par gérer le cas Google en passant un site en responsible. Pour celui d'OVH j'ai fait le minimum d'adaptation et je ne suis pas passé en UTF-8. Le site fonctionne en php 5.? à 98%. Il ne reste que quelques petits détails à régler mais pas trop de problèmes. Le plus gros a été de remplacer les anciennes commandes par pregreplace ou pregmatch.
 
WRInaute accro
Je m'adapte aux normes de codage et GG s'adapte à mon site ou va voir ailleurs.
Je l'ai codé avec les pieds et pourtant je suis très bien placé chez GG.
Donc qu'il continue à se démer...
 
WRInaute occasionnel
J'ai ce meme problème, avec la même deadline OVH. Mes é sont dans ma base données des é et je songe à faire un chercher/remplacer pour me sortir définitivement de ce problème.

Je veux dire récupérer ma base sur mon PC, l'ouvrir dans un éditeur de texte, faire un chercher/remplacer pour tous les caractères accentués, (à â ç é è ê etc...) et une fois que c'est propre, je remets la base sur mon serveur.

Le problème sera réglé, simplement et facilement. Où... J'aurais oublié quelque chose ?
 
Discussions similaires
C
Réponses
4
Affichages
2K
christele2
C
Haut