[Résolu] Problème de charset suite à la migration vers PHP 7

[gt57]

Bonjour à tous

Je suis sur un mutu depuis près de 20 ans sur OVH, et j'ai de nombreux sites sur cet hébergement, j'ai donc du attendre de pouvoir tout refondre pour faire ENFIN une migration de PHP 5 vers PHP 7.3. J'ai effectué la bascule ces derniers jours sans aucun problème... mais j'ai un souci que je n'arrive pas à résoudre depuis qui est apparu !

Depuis le passage du site en PHP 7, j'ai les fameux diamants noirs avec un point d'interrogation dedans, signe de caractères spéciaux non supportés par le charset, sur tout ce qui provient de ma BDD sql et qui contient des caractères "non latin".

Projet Deluxe: plus de 700 prototypes et �Beta Build� de...

Je précise que le site fonctionnait évidemment très bien avant la migration, je n'ai rien changé d'autre, et que tout a toujours été passé en UTF8 partout : en tête de site dans mes appels php, je fais un mysqli_set_charset en utf8, j'ai unsetlocale forcé sur fr_FR.utf8, mes sqli_query ont un SET NAMES en utf8 et dans les headers HTML de mes templates ensuite, je suis aussi en UTF8.

Ma database + mes tables sont toutes en collation utf 8, et le contenu qui se trouve dedans est censé l'être aussi. J'ai tenté des tas de méthodes trouvées partout sur internet (dont un script de conversion latin1 vers blob vers utf8, idem de utf8 vers latin1 vers utf8 etc) mais rien n'y fait, quand je les applique, le script tronque simplement les valeurs dès qu'il repère un mauvais caractère (par exemple, un é)

La seule solution viable pour l'instant, c'est quand j'ai appliqué un ini_set('default_charset', 'ISO-8859-1') en tête de page. A ce moment, tout ce qui provient de la BDD (en utf8) a été affiché correctement sur le site... mais dans ce cas, le reste de mon site (ce qui est en dur dans mon code HTML) affiche des caractères bizarres (Vidéos à la place de Vidéos ; 9,99€ à la place de 9,99€)

Est-ce qu'une solution pratique est possible ? Avez-vous une idée d'où cela provient ? Je me creuse la tète depuis trois jours mais je n'ai jamais eu de bugs de charset de ce type depuis 15 ans donc j'avoue sécher.

Merci par avance

[Fritz2cat]

�Beta Build�

Bizarre, vous êtes deux avec des questions similaires aujourd'hui.
https://community.ovh.com/t/changer-linterclassement-connexion-serveur/56019/2

Ma réponse est la même, pensez-vous que vous avez des caractères iso8859 dans une table déclarée utf8 ?

[gt57]

Bonjour

La base existe depuis 15 ans, il peut y en avoir sur les premières entrées, mais je suis certain que les entrées de ces 10 dernières années ont été envoyées avec un traitement utf8.

Deux questions le cas échéant : comment savoir quel est l'encodage d'un contenu (car si je regarde la table, elle sera forcément affichée en utf8, je parle bien de ce qui a été rempli) + en ce cas, une solution est possible pour tout convertir en entités utf8 ?

Merci pour l'aide

[Fritz2cat]

comment savoir

Pouvez-vous afficher le contenu à partir de phpmyadmin ?

[gt57]

Oui bien sûr. Voici un exemple d'un texte via son export sql

Elu fraîchement sauveur du petit éditeur français qui monte, à savoir Ubi Soft, le créateur Michel Ancel remet le couvert avec son héros sans bras ni jambes, mais pas sans foi ni loi, il s’agit bien entendu de Rayman. Vu le succès du premier opus, le défi va se révéler assez ardu.

et l'affichage client :

Elu fra�chement sauveur du petit �diteur fran�ais qui monte, � savoir Ubi Soft, le cr�ateur Michel Ancel remet le couvert avec son h�ros sans bras ni jambes, mais pas sans foi ni loi, il s�agit bien entendu de Rayman. Vu le succ�s du premier opus, le d�fi va se r�v�ler assez ardu.

[Fritz2cat]

export sql

Vous dites que c'est un export SQL.
Donc il est dans un fichier.

Vous avez regardé dans ce fichier avec un éditeur de texte ? lequel ?

Installez notepad++ (il existe aussi en version portable) et expérimentez

[gt57]

Oui pardon je n'étais pas clair, j'ai fait un export sql et j'ai ouvert dans mon sublime text, c'est bien UTF8 sans BOM

Notez que ca n'aide pas forcément à savoir la réalité du contenu, puisque avec phpmyadmin l'export peut être fait dans le charset qu'on veut, en l'occurrence celui que j'ai défini pour mes bases (utf8)

[Fritz2cat]

puisque avec phpmyadmin l'export peut être fait dans le charset qu'on veut, en l'occurrence celui que j'ai défini pour mes bases (utf8)

C'est pour cela que je vous suggérais de le visualiser dans phpmyadmin, on voit des accents ou des losanges ?

[gt57]

Tout s'affiche correctement avec les accents dans phpmyadmin
Pour reprendre l'exemple plus haut :

[Fritz2cat]

Tout s'affiche correctement avec les accents

alors je suis perdu aussi :(
désolé

[gt57]

OK, je ne suis pas fou alors, c'est bien incompréhensible.
Bon, en espérant que quelqu'un comprenne pourquoi j'ai ça depuis la migration PHP. OVH ne m'a pas répondu à la demande de support pour l'instant.
Merci quand même pour l'aide !

[Gaston_Phone]

Bon, en espérant que quelqu'un comprenne pourquoi j'ai ça depuis la migration PHP. OVH ne m'a pas répondu à la demande de support pour l'instant.

Bonjour @gt57

Je te propose cette manip en dernier recours.
A mettre au tout début de ton script :

ini_set('default_charset', 'iso8859-1');

[gt57]

La seule solution viable pour l'instant, c'est quand j'ai appliqué un ini_set('default_charset', 'ISO-8859-1') en tête de page. A ce moment, tout ce qui provient de la BDD (en utf8) a été affiché correctement sur le site... mais dans ce cas, le reste de mon site (ce qui est en dur dans mon code HTML) affiche des caractères bizarres (Vidéos à la place de Vidéos ; 9,99€ à la place de 9,99€)

Bonjour et merci pour l'idée, mais comme expliqué dans mon premier poste, ce n'est que déplacer le problème et ne résouds pas tout malheureusement :)
Bonne journée

[janus57]

Bonjour,

c'est que à un moment dans votre code c'est pas en UTF-8 d'après le comportement que vous indiquer.

C'est un site fait main ou un CMS ?
Vous avez fait un check de tous vos fichiers/fonctions pour vérifier que tout est bien en UTF-8 (y compris l'encode des fichiers) ?

Cordialement, janus57

[gt57]

Bonjour
C'est from scratch intégral, donc je connais tous mes scripts et normalement c'est donc OK
Sur l'exemple donné plus haut, pour un cas concret: la page est utf8, le contenu de la bdd et l'interclassement est utf8, et j'ai tout forcé en utf8 (headers et query) comme indiqué dans mon premier post, donc je ne sais pas à quel moment ça pourrait ne pas l'être dans le cheminement.

J'ai passé un mb_detect_encoding sur mes strings, et il me retourne bien utf8 d'ailleurs.

Quand vous parlez de fonction qui pourrait ne pas etre en utf8, à quelle fonction cela pourrait s'appliquer par exemple ?

Sur de nombreux encodes problématiques, il n'y a par exemple qu'un echo d'un item en provenance d'un array généré par mon foreach. Est-ce qu'un mauvais encodage peut venir directement d'ici ?

Merci pour l'aide
Cordialement

Edit: Je viens de tester de mettre un utf8_encode sur tous les elements affichés (mais ça va me prendre du temps et je pense que ce n'est pas l'idéal, d'autant que ca sera obso en php 8) et ça répare en grande partie. Les accents, les guillemets etc, tout s'affiche correctement, sauf quelques caractères comme le ’ ou le œ. En un sens, j'avance... ^^

[janus57]

Bonjour,

J'ai passé un mb_detect_encoding sur mes strings, et il me retourne bien utf8 d'ailleurs.

à priori cette fonction est plus une indication probable qu'une réel détection (Cf : https://www.php.net/manual/en/function.mb-detect-encoding.php)

à ce niveau un il faudrait un exemple concret avec une page.

Note : plus haut je parle également de l'encodage du fichier, je parle du script PHP (ou toute ressource incluse) et c'est vérifiable via notepad++, j'ai déjà eu un cas ou le code était compatible UTF-8, mais le fichier lui même était encodé en ANSI le résultat était un mix comme dans votre cas.

Je viens de tester de mettre un utf8_encode sur tous les elements affichés (mais ça va me prendre du temps et je pense que ce n'est pas l'idéal, d'autant que ca sera obso en php 8

peut être essayé avec https://www.php.net/manual/en/function.mb-convert-encoding.php
Par contre cela semble confirmer l'hypothèse d'un mix de charset, avant PHP7 vous étier en quelle version ?

Cordialement, janus57

[gt57]

Bonjour

Merci pour le retour

Par contre cela semble confirmer l'hypothèse d'un mix de charset, avant PHP7 vous étier en quelle version ?

Avant, j'étais en PHP 5.6

Note : plus haut je parle également de l'encodage du fichier, je parle du script PHP (ou toute ressource incluse) et c'est vérifiable via notepad++, j'ai déjà eu un cas ou le code était compatible UTF-8, mais le fichier lui même était encodé en ANSI le résultat était un mix comme dans votre cas.

Tous mes fichiers sont encodés UTF-8 : j'ai activé la detection du charset sur Sublime Text pour avoir tout de suite un oeil dessus et écarter cette possibilité. Je vais encore vérifier que tous les includes le sont aussi, mais comme je fais attention à ouvrir toujours toutes mes pages en UTF-8 depuis 10 ans, je pense qu'on peut l'écarter.

peut être essayé avec https://www.php.net/manual/en/function.mb-convert-encoding.php

J'avais effectivement aussi testé avec un mb convert encoding et la réaction est... surprenante : le string entier ne s'affiche plus. Du tout.

à ce niveau un il faudrait un exemple concret avec une page.

Pour un exemple concret, avec les exemples cités plus haut, vous pouvez vérifier sur https://www.gametrip.net/test-307-rayman-2-cas-rayman-r-ussi.html

Merci encore
Cordialement,

[Gaston_Phone]

Avant, j'étais en PHP 5.6

C'est bien ce que je pensais.

En date de décembre 2015 j'avais écrit :
OVH - PHP 5.6 - Mauvais affichage des caractères accentués

Pour un exemple concret, avec les exemples cités plus haut, vous pouvez vérifier sur https://www.gametrip.net/test-307-rayman-2-cas-rayman-r-ussi.html

Votre script débute bien par :

ini_set('default_charset', 'iso8859-1');

Si oui, serait-il possible de voir le texte original téléchargé par FTP sur votre PC ?

[gt57]

Mince, retour à mon premier post donc.
Il va falloir que je réenregistre à la main mes fichiers et templates UTF en ISO (et donc, sauf erreur de ma part, certains caractères ne passeront pas comme € ou oe) :

La seule solution viable pour l'instant, c'est quand j'ai appliqué un ini_set('default_charset', 'ISO-8859-1') en tête de page. A ce moment, tout ce qui provient de la BDD (en utf8) a été affiché correctement sur le site... mais dans ce cas, le reste de mon site (ce qui est en dur dans mon code HTML) affiche des caractères bizarres (Vidéos à la place de Vidéos ; 9,99€ à la place de 9,99€)

Dommage, merci :)

Edit: j'ai activé l'ini_set dans ma config, donc la version en ligne rafraichie présente la chose.

---

Désolé pour le double edit, je n'avais pas vu la fin

Si oui, serait-il possible de voir le texte original téléchargé par FTP sur votre PC ?

Pour un exemple concret : dans le menu, le mot Vidéos devient Vidéos avec l'ini_set

Le fichier :

 <li>
                    <a href="/videos.html" class="nav-links">Vidéos</a>
                </li>

[gt57]

Mise à jour mais pour moi ce n'est pas une vraie solution, je l'ai testé sur un serveur prod et non live :

Solution très sommaire et pas du tout optimisée: l'affichage devient fonctionnelle en passant un ini_set en iso8859-1 ET en mettant un utf_encode sur tous mes textes en dur dans les pages HTML et ce qui ne provient pas de la base. Ainsi je récupère mes accents et autres, sauf des caractères non pris en compte comme €.