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

OTP · 24 Juin 2015

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

spout · 24 Juin 2015

Ça vient de :
- Encoding des fichiers PHP
- Headers HTTP
- Meta charset
- Database / columns

OTP · 24 Juin 2015

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

spout · 24 Juin 2015

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à

OTP · 24 Juin 2015

Ok, merci, je vais fouiller ça.

OTP

indigene · 24 Juin 2015

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

spout · 24 Juin 2015

indigene a dit:
toujours écrire et stocker en base les caractères accentués de cette façon :

é = & e a c u t e ;

Surtout PAS !

indigene · 24 Juin 2015

spout a dit:
Surtout PAS !

peux-tu développer s'il te plait ? Je fais comme ceci depuis 1999 en utilisant htmlentities et des choses comme ça et je n'ai jamais rencontré de problème.

Blount · 24 Juin 2015

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.

spout · 24 Juin 2015

C'est des légendes urbaines.
Si plus tard ces données tu dois les afficher/traiter autre part que dans du HTML (JSON/API/autre) ?

Compléments:
http://stackoverflow.com/questions/1970880/store-html-entities-in-data ... -retrieved
http://stackoverflow.com/questions/9299152/do-i-need-to-use-html-entit ... e-database

OTP · 24 Juin 2015

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 !

spout · 24 Juin 2015

OTP a dit:
C'est à dire il faut faire quoi .

Vérifier l'encoding (UTF-8 sans BOM) des fichiers

OTP a dit:
Dans le header j'imagine ? Rien trouvé de tel

Le problème n'est pas là non plus alors.

OTP · 24 Juin 2015

spout a dit:
OTP a dit:

C'est à dire il faut faire quoi .

Cliquez pour agrandir...

Vérifier l'encoding (UTF-8 sans BOM) des fichiers

C'est à dire reprendre l'encodage de TOUS mes fichiers ???

spout · 24 Juin 2015

Ben oui, vérifier que t'as pas un mix de ISO / UTF8. Tu px le faire en ligne de commande (linux) avec iconv/recode:
http://stackoverflow.com/questions/64860/best-way-to-convert-text-file ... acter-sets
http://www.ycerdan.fr/linux/convertir-des-fichiers-en-utf-8-sous-linux/

indigene · 24 Juin 2015

Blount a dit:
Les données mise en base doivent être comme elles ont été fournies.

Exact, c'est uniquement à l'affichage que j'utilise htmlentities. Pour le stockage c'est du addslash

spout · 24 Juin 2015

Pr le stockage c'est plutôt du mysql_real_escape_string() (si tu utilises tjs mysql_*).
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

indigene · 24 Juin 2015

spout a dit:
Pr le stockage c'est plutôt du mysql_real_escape_string() (si tu utilises tjs mysql_*).
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

Pas si on est en Latin-1 (ISO 8859-1). Le addslashes est suffisant (confirmé plus bas dans le même article)

OTP · 24 Juin 2015

spout a dit:
Ben oui, vérifier que t'as pas un mix de ISO / UTF8. Tu px le faire en ligne de commande (linux) avec iconv/recode:
http://stackoverflow.com/questions/64860/best-way-to-convert-text-file ... acter-sets
http://www.ycerdan.fr/linux/convertir-des-fichiers-en-utf-8-sous-linux/

Ok, merci !!!

noren · 24 Juin 2015

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.

indigene · 24 Juin 2015

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.

OTP · 24 Juin 2015

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...

indigene · 24 Juin 2015

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.

OTP · 24 Juin 2015

spout a dit:
Ben oui, vérifier que t'as pas un mix de ISO / UTF8. Tu px le faire en ligne de commande (linux) avec iconv/recode:
http://stackoverflow.com/questions/64860/best-way-to-convert-text-file ... acter-sets
http://www.ycerdan.fr/linux/convertir-des-fichiers-en-utf-8-sous-linux/

Back...
Pourquoi avec un encodage ISO et le charset ISO, ça ne marche pas ???

OTP · 24 Juin 2015

indigene a dit:
ultimatum de Google pour 21 avril 2015

Celui là je m'en bats les flancs !

indigene · 24 Juin 2015

OTP a dit:
Celui là je m'en bats les flancs !

On peut plus facilement changer d'hébergeur que faire changer tout le monde de moteur de recherche

OTP · 24 Juin 2015

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...

elji · 3 Août 2015

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 ?