Bonjour,
J'ai développé depuis une dizaine d'année une comptabilité personnelle hébergée sur mon site. Je maintiens régulièrement celle-ci en particulier avec l'évolution de php et parfois de petites modifications.
Récemment les accents du texte contenu en base de donnée pour le libellé, la nature et le nom du compte concernant les opérations comptables sont remplacés par un point d'interrogation dans un losange alors que les accents des textes hors base de donnée sont corrects.
Cette modification est arrivée (je pense) lors de la modification par ovh de la méthode de login des bdd.
Entre le moment où les accents étaient correctement représentés et leur passage en ? je n'ai effectué aucun travaux sur le site.
Je suis encodé en utf_8 (notepad++) :
header('Content-Type: text/html;charset=UTF-8');
et
Avez-vous une idée ?
Merci par avance.
*** SOLUTION ***
Il faut ajouter dans le script de connexion à la base de donnée si vos requêtes sont en mysqli : mysqli_set_charset
avec une instruction du genre :
> if (!mysqli_set_charset($link, "utf8mb4")) { …}
Bonjour,
vous avez vérifié votre encodage dans la BDD et l'encodage de la connexion avec la BDD ?
Cordialement, janus57
Oui, comme précisé dans mon message et pour la BDD utf8_unicode_ci.
Mais tout ceci n'expliquerai pas pourquoi du jour au lendemain pourquoi les accents des textes en BDD ont disparus.
Bonjour,
Oui, comme précisé dans mon message et pour la BDD utf8_unicode_ci.
oui et non car le code de connexion peux influencer, c'est pas parce que votre fichier est encodé en UTF-8 que la connexion entre votre script PHP et la BDD sera forcément en UTF-8.
Mais tout ceci n'expliquerai pas pourquoi du jour au lendemain pourquoi les accents des textes en BDD ont disparus.
Alors là y a une différence : dans un dump les accents sont présent ou pas ?
Si oui alors le problème est au niveau du/des scripts.
Si non alors la BDD a été touché et ça c'est pas normale.
Cordialement, janus57
Bonjour,
je précise.
A J 22h00, je vais me coucher, tout marche bien, les accents sont présents ; à J+1 08h00 je me lève, les accents des textes issus de la BDD sont remplacés par les "losanges ?", les textes issus du code ont les accents bien présents. Voir la copie d'écran ci-dessous :
Ceci correspondant (du moins je pense sans pouvoir l'affirmer) au changement de nommage des BDD .
D'autre part quand j'ai ouvert ma base avec phpmyadmin il a fallu 20mn pour que les tables soient toutes affichées et je les voyais apparaître les unes après les autres comme si ça travaillait chez OVH.
Bonjour,
Au risque de paraître chiant, c'est typiquement un problème d'encodage.
La seule chose que OVH fait en ce moment comme manipulation c'est de remplacer les anciens nom des SQL par les nouveaux avec une configuration plus récente sur une nouvelle infrastructure de gestion des connexions.
La BDD en elle même n'est pas altéré.
Par contre cela du réveiller le fait quelques part dans votre code soit un fichier est pas en UTF-8 soit vous avez une fonction qui a un moment forcé en mode iso-8859 ou latin ou ansi.
Cordialement, janus57
Merci pour tes réponses et je vais creuser ce pb d'encodage possible quelque part dans un script en iso-8859 puisque effectivement à sa création mon site utilisait cet encodage que j'ai modifié il y a plusieurs années.
Voici les traces dans mes scripts de ces modifications.
Dans le code php :
> //
> / PASSAGE en UTF8 /
> //
> header('Content-Type: text/html;charset=UTF-8');
> //header('Content-Type: text/html;charset=iso8859-1');
> //
Dans le code html : j'ai supprimé le caractère "<" en tête de ligne autrement les lignes sont interprétées et n'apparaissent pas dans le msg.
> !–//
> /** PASSAGE en UTF8 /
> //—>
> META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
> !–META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso8859-1"–>
> !–/***/—>
Dans la BDD :
> utf8_unicode_ci
Par contre la BDD a bien été modifiée, on voit des caractères bizarres qui sont apparus mais sans liens évidents avec le problème.
exemple 1
> 1243
> rep
> 0
> 1
> 0
> userA
> 2021-07-31 17:22:35
> 2021-08-28
> RETRAITE du MOIS de août
> Vir_C
> 9
> [BLOB - 16 o]
> [BLOB - 16 o]
> cpteA
> -
> 0
exemple 2
> 1233
> rep
> 0
> 1
> 0
> userA
> 2021-08-12 17:58:48
> 2021-08-05
> Orange m�tro JC (Mobile-Livebox-Tv-Internet)
> Pr�
> 1
> [BLOB - 16 o]
> [BLOB - 16 o]
> cpteA
> -
> 0
Je te remercie de l'aide que tu m'apportes et je vais rechercher un éventuel script dans lequel il trainerait une référence à iso-8859.
Cordialement.
Bonjour @Jean-ClaudeC2
Peux-tu faire un essai en mettant au tout début de ton script :
> ini_set('default_charset', 'iso8859-1');
Oui, je vais essayer mais il n'y a pas qu'un seul script en cause.
En fait, j'avais déjà essayé et ça ne change rien.
Bonjour,
Vous les sortez comment vos exemples ?
Que donne un dumping via le manager OVH au niveau du contenu (ouvert avec notepad++ ou Geany) ?
Cordialement, janus57
août
Ça c'est typiquement du UTF-8 affiché comme si c'était du ISO-8859. Je pencherais plutôt pour un problème d'affichage que de stockage dans la BDD.
m�tro
Ceci m'inspire beaucoup moins. Quel mot est caché là-derrière ?
métro
Vous les sortez comment vos exemples ?
Mes exemples proviennent de phpmyadmin dont voici une copie d'écran. On retrouve mes 2 exemples en lignes 1233 et 1243.
Mais je ne trouve pas de correspondance entre la modification de la BDD et les défauts d'affichage et je vous rappelle que seuls les accents des textes issus de la BDD sont impactés.
Que donne un dumping via le manager OVH au niveau du contenu (ouvert avec notepad++ ou Geany) ?
Je ne comprend pas la question ou plutôt je ne vois pas quoi faire !
La comptabilité comporte 183 fichiers dans 19 répertoires avec une quinzaine de fichiers impliqués dans la lecture des tables et l'affichage. Je les ai tous passés en revue et sauf oubli de ma part, ils sont bien codés en Utf-8. J'utilise Notepad ++.
Cordialement.
métro
Un article: https://webmasters.stackexchange.com/questions/129739/special-characters-from-iso-8859-1-encode-website-come-out-mangled-%C3%AF-%C2%BD-in-goog
Cette substitution ne semble pas réversible car tous les caractères accentués dans l'article sont remplacés par la même chaîne "�"
Par prudence, vérifier avec phpmyadmin que la base de donnée contient bien les chaînes de caractères intactes. (et pas que les blobs)
J'ai fait toutes les vérifs dans maintenance de la table et toutes me répondent "Ok"
J'avoue que je suis découragé car je ne sais plus quoi faire et je suis sûr de n'avoir rien modifié car j'étais hospitalisé quand ça s'est passé.
Y a t'il eu une maj de php ou autre ?
Cordialement.
Bonjour,
Je ne comprend pas la question ou plutôt je ne vois pas quoi faire !
via le manager OVH télécharger une sauvegarde sur votre PC puis ouvrez la sauvegarde avec un éditeur (genre notepad++ ou Geany) pour voir comment sont les données.
Car j'aurais plus confiance dans la vérification comme ça que via phpMyAdmin, car la sauvegarde du manager est fait avec mysqldump.
Cordialement, janus57
Ah, ok
J'ai déjà fait mais c'est inexploitable du moins pour moi.
Je vous joint le fichier de la table k.compta-4 sauvegarde vue par notepad ++.
Je ne peux pas l'envoyer car les fichiers txt ne sont pas autorisés, voici donc une copie d'écran du début du fichier.
Cordialement.
Bonjour,
ah là par contre c'est bien les données qui sont touchés.
Vous avez remarqué le soucis quand ?
Vous avez une sauvegarde d'avant le problème ?
Les seules interventions récentes sont : http://travaux.ovh.net/?do=details&id=52378& + http://travaux.ovh.net/?do=details&id=52594&
Mais vu que c'est justement une bascule d'infra (move de VM et/ou containers) ça impact pas les données normalement (si la date correspond).
Avec le nom du serveur SQL peut être que @MikaelD1 (qui est un employé OVH spécialisé sur les produit databases si j'ai bien compris) pourrais check, mais pas sûr si c'est une base mutu.
Cordialement, janus57
Voici un lien pour ouvrir la table k.compta-4.
https://www.dropbox.com/s/7w064qm3l1vcqh6/table%20k.compta-4.txt?dl=0
Après transfert il faut l'ouvrir dans notepad ou autre.
Je suis sur une autre piste, je vous tiens au courant.
Cordialement.