Encodage avec mysql 8

Ãc pour é par exemple

Ce qui semble être un caractère UTF-8 affiché en ANSI.

Au lieu de Notepad, passez à Notepad++ qui a vraiment une panoplie de conversions disponibles.

En fait il faudrait voir:
- le contenu de vos tables si du texte affiché provient de la base de données
- le contenu de vos fichiers si le contenu affiché provient de ceux-ci (mais alors que vient faire MySql8 dans l'équation ?)
- la manière dont vous affichez vos pages et en particulier la balise ``

Quelle est l'adresse de votre site et comment a-t-il été réalisé ?
Si c'est avec un CMS est-il à jour ?

Merci beaucoup pour ces informations.
Il s'agit d'un site wordpress récent (2023) mais sa bdd est l'addition de tables wp et des tables d'une base de données ancienne (2014) qui répond à un Modèle Vue Controleur pour rechercher des articles dans une revue:
http://bdd.samb-baiona.net/controleur.php?action=action_accederModuleDeRecherche
Les caractères accentués s'affichent correctement dans le fichier sql exporté et ouvert avec Notepad++.
C'est bien Notepad++ que j'utilise.

base de données ancienne (2014)

Quand vous naviguez dans la base avec phpmyadmin, est-ce cohérent ?

Dans votre export consulté avec notepad++
Chaque table a son propre character set.

Tu peux rajouter mysqli_set_charset($link, "latin1"); aprés ta connexion à Mysql il remettra l'encodage mais si tu est au dessus de php 5.6 il faut que tu ajoute également ini_set('default_charset', 'iso8859-1'); dans ton code, bonne soirée !

Pour les anciennes tables je vois:
ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
et pour les tables wp:
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
mais je ne sais absolument pas quoi en penser

Rebonjour,
La lecture de la base indique ceci pour les tables anciennes:
ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
Par ailleurs j'avais déjà converti les fichiers php anciens que Notepad++ affichait comme ANSI en UFT-8 (sans BOM) et ce sont donc des UTF-8 qui sont en ligne. Mais cela n'avait pas apporté de solution. D'où ma question initiale.
Du coup je ne sais si la proposition de Pierre-Arnaudb reste valable. Faut-il remettre les ANSI sauvegardés avant de modifier le code comme suggéré ?

Vous n'avez pas été faire un tour avec PHPmyAdmin pour voir si ça déraille aussi à ce niveau, à la consultation de vos données ?

L'affichage est correct dans les contenus de tables en affichant la bdd par phpMyAdmin. Rien d'anormal de ce côté.

Dans votre cas je ne sais pas comment je m'y prendrais.
Exporter la table litigieuse,

RENAME TABLE
tbl_name TO new_tbl_name

bidouiller ou pas ce fichier export (soit conversion de jeu de caractères avec n++ ou bien changer le charset) et réimporter ????

Merci bien pour ces conseils.
Je viens de faire le tour de l'encodage des fichiers dans une version ancienne sauvegardée de la bdd, c'est à dire une version qui affichait correctement. Je pense que la migration en mysql 8 révèle des encodages mélangés qui mettent en défaut l'affichage:
- les fichiers php sont en grande majorité en encodage ANSI d'après Notepad++ mais j'en vois aussi un en UTF-8 (le controleur.php)
- les fichiers html sont: soit en UFT-8, soit sans indication mais ce sont ceux qui comportent une balise meta avec ISO-8859-1
La seule modification dans cette structure a été en 2023 la modification de code de mysql vers mysqli.
Une solution ne serait-elle pas de repartir des fichiers anciens, de tout convertir en UFT-8 avec Notepad++ et de modifier les charset des fichiers qui ont une balise meta ?

La seule modification dans cette structure a été en 2023 la modification de code de mysql vers mysqli.

Bonjour @fc909e5c16759f58a8d2

Je ne vois pas le rapport.
Pour moi, le passage de **_mysql_** vers **_mysqli_** ne concerne la connexion et les requêtes vers la base de données.
Pas la structure de la base de données.

Oui bien sur. C'était juste façon de d'indiquer que ces fichiers anciens n'avaient pas été modifiés (à part les lignes concernées par la migration mysql vers mysqli).

Y a-t-il une explication au fait que le navigateur (Firefox mais aussi Chrome) affiche en iso-8859 alors que les fichiers php et html actuellement sur le site sont encodés en utf8 ? Est-ce l'encodage que l'on trouve avec Notepad++ pourrait ne pas refléter la réalité ?

Bonsoir @fc909e5c16759f58a8d2

Je ne vois pas votre problème, sur les pages :

* https://nouveau.samb-baiona.net/bulletin-du-musee-basque/
* https://samb-baiona.net/event/philippe-veyrin-artiste-et-cofondateur-du-musee-basque/

Tous les caractères accentués s'affichent correctement. Test avec EDGE, VIVALDI et FIREFOX.

Par contre pour la recherche **_EUSKADI_** sur la page :
http://bdd.samb-baiona.net/controleur.php?action=action_rechercher
L'affichage est horrible.

Est-ce la même base de données ?

Sur FIREFOX :



Sur VIVALDI :

Merci Gaston_Phone.
Il s'agit d'un site wordpress récent (2023) mais sa bdd unique est l'addition de tables wp et des tables d'une base de données ancienne (2014) qui répond à un Modèle Vue Controleur pour rechercher des articles dans la revue.
Il n'y a que les tables de la bd de la revue qui affichent mal. J'ai converti ces tables en utf8 et mis des charset utf8 dans les pages html concernées. Malgré tout cela l'affichage incorrect persiste. Je devrais peut-être revenir aux versions anciennes (ANSI et iso-8859) et mettre du code ad hoc en tête du php qui renvoie l'affichage ?

Bonjour @fc909e5c16759f58a8d2

A tout hasard, voir : https://www.wordetweb.com/word-et-web/OVH-php-5.6-mauvais-affichage-caracteres-accentues-resolu-FR.htm

Après beaucoup de modifications et essais, la bdd ancienne s'est remise à afficher correctement. J'ai inséré le bout de code mysqli_set_charset ($connexion, "latin1"); dans 5 fichiers php juste après le code de connexion. Ce que Pierre-ArnaudB proposait. Je suis en php 8.2 mais n'ai pas inséré le ini_set.
Un grand merci à tous les trois pour votre support et votre aide.