Caractères accentués avec PHP 5.6 chez OVH

**wikimaginot** · 13/10/2015, 08h08

Bonjour

J'ai eu un problème très similaire avec les caractères accentués. La configuration serveur, Mysql et PHP n'étaient en rien responsable de ce souci comme bien souvent imputable à la seule interface fauteuil-clavier (moi...

)

Les pages du site contenant un mix de PHP et html étaient créées à partir d'une page type codée en UTF 8. Tout cela fonctionnait très bien, mais l'affichage de certaines pages ou parties de page posait problème au niveau de l'affichage des caractères spéciaux. J'ai essayé comme toi toutes sortes d'astuces et bidouilles mais aucune n'a solutionné le problème.

Ce dysfonctionnement était lié à la bibliothèque de fonctions php utilisée par une majorité des pages du site. Cette bibliothèque est dans un fichier .php séparé et celui ci était codé en ISO . Cela était du à la configuration de base de Dreamweaver qui utilisait l'encodage ISO par défaut lorsque je créai une page php vierge. Il m' a suffit de modifier avec dreamweaver le codage de cette page et de quelques autres scripts pour que tout rentre dans l'ordre.

Pascal

http://wikimaginot.eu

**boteha** · 13/10/2015, 10h31

Bonjour,

Merci de ton message.

Tu confirmes qu'il faut ré-enregistrer les scripts un par un, comme déjà indiqué.

**boteha** · 06/08/2016, 14h49

Bonjour,

Si j'ai bien compris je dois convertir tous mes fichiers qui éditent du texte en UTF-8.

1) Pour les scripts qui ne traitent pas de texte je suppose que la conversion est inutile.

2) Dans Notepad++ il y a deux formats d'encodage UTF-8:
Convertir en UTF-8 (sans BOM)
Convertir en UTF-8

Lequel choisir ?

Merci d'avance.

**sabotage** · 07/08/2016, 12h21

UTF8 sans BOM et converti tous tes fichiers.

**boteha** · 07/08/2016, 12h37

Bonjour Sabotage,

Merci de ta réponse, donc UTF-8 (sans BOM).

1) Faut-il aussi convertir les fichiers .css ?

2) Dans Notepad++, menu Encodage > Convertir en UTF-8 (sans BOM)
Et ensuite faut-il ré-enregistrer le fichier ou Notepad++ le fait-il à la conversion ?

**boteha** · 07/08/2016, 12h57

Bonjour,

Envoyé par wikimaginot

Il m' a suffit de modifier avec dreamweaver le codage de cette page et de quelques autres scripts pour que tout rentre dans l'ordre.http://wikimaginot.eu

Comment fais-tu pour modifier l'encodage par défaut de Dreamwaever ?
Par les préférences je n'y suis jamais arrivé ni sur windows ni sur mac.

Maintenant j'utilise Notepad++ qui semble plus clean.

**ABCIWEB** · 11/08/2016, 22h18

Envoyé par boteha

Bonjour,

Pourquoi header et pas une balise meta ?

Et où dois-je placer header,, pas dans le <head> ?

Encore merci.

Parce que l'entête php à la priorité sur la balise meta html.

Si donc l'entête php par défaut est utf-8, tu ne pourras utiliser ISO que si tu spécifies une autre entête php en remplacement (celle que t'a donnée sabotage ici). Il faut placer cette entête le plus haut possible dans ton code php.

En fait la balise meta html n'est efficace que pour du html pur (quand il n'y a pas de php). Ou il y a une autre solution avec AddDefaultCharset Off pour que le serveur se renseigne sur l'entête http mais cela demande modifier le fichier "httpd.conf" d'apache.

Si tes fichiers incluent un fichier commun le plus pratique est de mettre l'entête (header...) à l'intérieur de ce fichier commun.

EDIT : Oup's j'ai répondu par rapport au dernier message de la page précédente...

Enfin bon si tu est parti pour tout convertir en utf-8, c'est finalement mieux même si cela te feras plus de travail. C'est le standard actuel et permettra une meilleure évolutivité de tes scripts php et javascript.

**boteha** · 12/08/2016, 12h35

Bonjour,

Merci de tes précisions.

Envoyé par ABCIWEB

Enfin bon si tu est parti pour tout convertir en utf-8, c'est finalement mieux même si cela te feras plus de travail. C'est le standard actuel et permettra une meilleure évolutivité de tes scripts php et javascript.

C'est ce que je compte faire sans doute pendant ce week-end.
Une gfois en utf-8 j'essaierai de passer en PHP 7.

**boteha** · 13/08/2016, 18h01

Bonjour,

Sur mon site de test, j'ai :
1) Ouvert les scripts sous Notepad++
2) Encodage > Convertir en UTF-8 (sans BOM)
3) Enregistrez-nous
Par défaut le type PHP est sélectionné, je ne change rien.

Si j'ouvre le fichier, en local c'est bon.
Par contre, quand je remets sur le serveur avec Filezilla c'est la catastrophe, tous les retours à la ligne disparaissent.
Le script ne peut plus être exécuté : FATAL ERROR.

Je précise que le problème n'apparaît pas avec tous les scripts, seulement certains, c'est encore plus vicieux.
Comme cela ne se voit en local il va falloir tout vérifier au niveau du serveur.

Faute à Filezilla ?
C'est le même que j'utilise tous les jours.

Merci de votre aide, je ne m'attendais pas à cette galère.

**ABCIWEB** · 13/08/2016, 18h18

Essaies de faire afficher les erreurs sur ton serveur distant, en haut du code des pages qui posent problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
error_reporting(E_ALL);
ini_set('display_errors', 1);

tu y verras peut-être plus clair.

EDIT : autre possibilité copies tout le code de l'ancienne page dans une nouvelle (vierge) qui vient d'être créée avec l'utf-8. Parfois cela permet de résoudre le problème.

**boteha** · 13/08/2016, 18h41

Bonjour,

Je ne suis pas le seul à avoir ce problème, il y a des réponses sur le Web, par exemple :

Pour éviter ces problèmes, il suffit de ne travailler qu'en binaire. Donc dans les paramètres Filezilla / Transferts / Types de fichier, il faut cocher "Binaire".
Et là, magie, les encodages ne sont plus convertis (même comportement que Cyberduck) et tout le monde est content. Mes fichiers en Mac ANSI restent en Mac ANSI.

Effectivement cela a l'air de fonctionner.

La plupart de mes fichiers ont été créés sur Mac et je suis passé sur PC.
Je vois que après encodage UTF-8 et enregistrer sous, les fichiers restent avec des sauts de ligne Mac.

**boteha** · 13/08/2016, 18h57

Bonjour,

Je découvre un nouveau problème.

Sur la page d'accueil, le site dit bonjour au client en allant chercher un cookie créé quand le client s'enregistre.

Ce cookie est un minuscule fichier texte avec ££ en séparateur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
$_COOKIE['site'] = 'prenom££nom';
 
$tab = explode ('££', $_COOKIE['site'];
 
$bonjour = 'Bonjour ' . $tab[0] . ' ' . $tab[1];

Depuis passage en UTF-8, le séparateur ££ devient ��, donc explode ne fonctionne plus...

**boteha** · 13/08/2016, 21h50

Envoyé par boteha

Depuis passage en UTF-8, le séparateur ££ devient ��, donc explode ne fonctionne plus...

J'ai vu que l'on peut régler ce problème avec utf8_encode () ou icony ()
Je me demande quel est le meilleur.

iconv ("ISO-8859-1", "UTF-8", $text)

Bien sûr j'ai un problème équivalent avec toute la base de données qui est encodée en latin-1.
Je peux la réencoder par PHPMyAdmin mais ça fait un peu peur.

**ABCIWEB** · 14/08/2016, 03h57

Si tu es obligé d'utiliser utf8_encode () c'est que tu as un problème d'encodage quelque part dans ton code ou que ton fichier n'est pas correctement encodé en utf-8. Tentes le copier /collé que j'ai indiqué plus haut car parfois la modification d'encodage des fichiers fonctionne mal. En faisant cela tu sera au moins certain que cela ne vient pas de l'encodage du fichier lui-même.

Pour le reste, tu devrais suivre un tuto sur l'utf-8. Celui donné en lien est un peu ancien, mais sur le fond tu devrais trouver des informations qui te serviront. Juste le header en php n'est plus indispensable puisqu'il est par défaut en utf-8 avec php5.6.

Et pour la bdd si tu utilise mysqli la commande adéquate est mysqli_set_charset ( mysqli $link , string $charset ) alors qu'avec pdo le mieux est de passer l'encodage dans la connexion :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$pdo = new PDO('mysql:host='.$hostname.';dbname='.$database.';charset=utf8', $username, $password, $options);

Il faudra aussi modifer les charset des champs de bdd vers utf-8 (souvent general_ci pour dire casse insensitive) dans phpmyadmin.

**boteha** · 14/08/2016, 19h50

Bonjour,

Merci pour les conseils et le tuto.

Comme expliqué dans le tuto un changement d'encodage n'est pas une partie de plaisir.

Maintenant mon but n'est pas de changer d'encodage pour le plaisir.

L'idée est de passer de PHP 5.5 à PHP 5.6 ou 7.

Puis-je le faire en conservant mon encodage iso-8859-1 ?

Par ailleurs j'utilise le forum miniBB dont les scripts sont en UTF8 mais qui semble encodé en iso-8859-1, c'est du moins ce que la balise meta annonce.

**ABCIWEB** · 15/08/2016, 02h24

Envoyé par boteha

L'idée est de passer de PHP 5.5 à PHP 5.6 ou 7.
Puis-je le faire en conservant mon encodage iso-8859-1 ?

On t'a déjà répondu sur le sujet notamment ici.

L'inconvénient de l'iso est que des lib javascript comme jquery ne sont compatibles qu'avec utf-8, idem pour des fonctions php comme json_encode. Après tu peux toujours utiliser utf8_encode () / utf8_decode pour compenser mais le standard actuel est clairement utf-8. Cela facilite l'interaction entre les scripts et permet aussi de faire afficher différentes langues dans une même page, par exemple tu peux faire une citation en japonais dans une page en français.

Mais bon pour un site déjà installé en iso tu peux travailler en iso au moins jusqu'en php 5.6 (j'ai pas testé avec php7). Par exemple pour ce petit site qui a plus de dix ans, j'ai simplement ajouté l'entête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

header('Content-Type: text/html; charset=ISO-8859-1');

en haut de mes pages php pour le faire fonctionner en php 5.6 chez OVH. Après quand il s'agira de passer à php7, étant donné qu'il faudrait refaire les requêtes mysql ce sera le moment de tout rénover.

**boteha** · 15/08/2016, 13h07

Bonjour,

Envoyé par ABCIWEB

Après quand il s'agira de passer à php7, étant donné qu'il faudrait refaire les requêtes mysql ce sera le moment de tout rénover.

Merci de tes réponses.

Je suis en mysqli, je ne pense pas avoir à changer mes requêtes pour PHP7.

Pour l'instant je tente 5.6 avec ta solution de header.

Donc :
1) Je conserve mes fichiers en ANSI.
2) Quand un script pose problème, j'ajoute derrière Session_Start ()
header ('Content-Type: text/html; charset=ISO-8859-1');

Ce qui est bizarre c'est tous les scripts ne posent pas problème...
J'ai plein de scripts ANSI qui affichent bien les caractètres spéciaux sans toucher au header.

3) Pour l'édition du code j’utilise maintenant Notepad++ sous W10, mais j'ai pendant très longtemps utlisé Dreamwaver sous Mac ou PC XP.
Certains scripts sont à saut de ligne Macintosh, d'autres Dos/Windows et certains UNIX.
Cela ne pose pas de problème au serveur mais est-il conseillé d'unifier ?

**ABCIWEB** · 15/08/2016, 17h45

Normalement la fonction nl2br utilisée pour gérer les retour lignes est compatible avec les systèmes MAC, WINDOW et UNIX.

Envoyé par nl2br

Retourne string après avoir inséré <br /> ou <br> devant toutes les nouvelles lignes (\r\n, \n\r, \n et \r).

Pour tes différents scripts, peut-être certains ont du texte écrit en dur dans la page, ou d'autres font appel à la bdd et encore d'autres ni l'un ni l'autre, ce qui peut expliquer les différences.

**boteha** · 15/08/2016, 18h41

Bonjour,

Merci de ta réponse.

**boteha** · 15/08/2016, 21h28

Bonjour ABCIWEB,

Je vais mettre ta science de l'encodage avec un problème incompréhensible.

J'ai un script qui envoie plein de mails divers et variés : devis, factures, alertes, etc.

J'utilise PHPMailer chez OVH.

Tout se passe généralement bien, sauf pour quelques types de mail dont l'objet sort ainsi dans le header du mail :

?ISO-8859-15?Q?monsitte.com_:_SUIVI_de_votre_devis_11, _proposition_?= d'échange

Le bug sera répété systématiquement.

Par contre le body est correct.

Tu enlèves ton apostrophe et les caractères accentués, cela sort bien.

monsite.com : SUIVI de votre devis 11, proposition de substitution

Dans le même script, d'autres messages avec apostrophes et caractères accentués sortent bien...

As-tu idée d'une solution, je crois qu'il ne faut pas chercher à comprendre.

Peut-être un problème chez OVH mais ils ne m'ont pas répondu.

J'ajoute une info.
Le problème n’apparait pas si tu envoies tes mail avec isSMTP
Il se manifeste avec isMail
Le problème est que isSMTP fonctionne très mail chez OVH, temps de réponses affreux et la moitié des mails qui n'arrivent jamais.

Caractères accentués avec PHP 5.6 chez OVH

Langage PHP

Discussions similaires

Partager

Partager