Problèmes caractères accentués sur 1-CLIC

évite toute manipulation aveugle

c'est un souci dû à la migration de ton cluster07, et de ton hébergement non maintenu

quelle est ton offre d'hébergement ? perso/pro/...
dans le dossier `www`, as tu un fichier `.ovhconfig` ?
au dessus de `www`, as tu un fichier `.ovhconfig`?
si oui, quel est son contenu?
si non, ce que je pense, peux tu en créer un avec dedans:
```text
app.engine=php
app.engine.version=7.2
http.firewall=none
environment=production
container.image=stable
```
est ce suffisant pour corriger?

Merci de votre réponse et de cette nouvelle piste.
Mon hébergement est..."perso2014" (notez j'ai régulièrement demandé à OVH si je devais le faire évoluer, on m'a dit pas la peine)
J'ai un fichier .ovhconfig dans le WWW, qui dit
"app.engine=php
app.engine.version=5.4
http.firewall=none
environment=production"

Et j'ai bien un fichier .ovhconfig au-dessus de WWW, qui dit la même chose :
"app.engine=php
app.engine.version=5.4
http.firewall=none
environment=production"

J'ai modifi2 les 2 avec ce que vous m'avez indiqué.
Pour le moment ça ne suffit pas à corriger.

tu peux supprimer celui de `www`
il restera celui de tête qui est lui géré par le manager
je te vois bien en php7.2
tu as bien mis stable?

Donc voilà à nouveau un problème d'encodage comme nous en parlons sur
https://community.ovhcloud.com/community/fr/probleme-sur-bd-lie-au-transfert-vers-graveline?id=community_question&sys_id=efe5fdc0e5d286d02d4c0165b3e7669d

OVH doit faire quelque chose

Ok supprimé celui de www.
Oui j'ai mis 7.2 et stable dans le Manager OVH (si je fais "modifier la config actuelle", je tombe sur 7.2 et stable.

au lieu de polluer les autres et de piétiner, si tu ouvrais TON sujet !
puisque tu sais tout, pourquoi as tu besoin de venir ici, appelles le support
et si tu regardais le forum au lieu de piaffer, tu verrais que c'est le troisième cas de figure
pour le 4e je pense pas que tu comprennes

sais tu te servir de phpMyadmin ?
peut exporter la table `*_posts` en iso-8859-15 ?
peut exporter la table `*_posts` en utf-8 ?

dans un éditeur de texte, genre notepad++, tu me dis si tu vois des caractères accentués corrompus

C'est fait, l'export UTF8 me donne ce que j'avais tout à l'heure en export (é = xE9, corrigé si je mets Notepad++ en ANSI)
Export ISO-885915 => me fait un export incomplet, fichier de 84 ko (l'UTF8 fait 4 Mo)
Bizarre ?? J'ai loupé quelque chose ?
En tout cas dans l'ISO-885915 je trouve ça par exemple :
"m?lange de formation" => corrompu, n'est-ce pas ?

si tu ouvres un export en UTF8 tu NE DOIS pas mettre notepad++ en ANSI ou il ne doit pas s'y mettre

A l'ouverture Notepad++ était en UTF8 j'ai voulu faire ce test (ANSI), je le laisse en UTF8.

lors de l'ouverture en standard, uft-8, c'est correct ou pas?

@SebastienL28 va être décu, Karine n'a pas encore migré et est encore à Paris :)

Comme tu me l'as si aimablement fait remarqué, pourquoi me réintégrer dans cette conversation ?
Ravi pour Karine.

je sais pas où on peut voir ça, c'est annoncé par Ovh, et je tatouille pour avoir une idée si c'est en cours ou en préparation
mais en fait c'est réalisé filer par filer

pour karine, fausse piste
la base est toujours bien déclarée en utf8, mais en latin1 effectif...
ça sent le bug Ovh, je regarderai ce soir à corriger et migrer ça (c'est sur un vieux serveur mySql 5.1)

je t'ai dit, la déclaration uft8 est correcte !

j'ai dit **DÉCLARATION UTF8** correcte, de mémoire
si tu veux d'occuper de ça, tu contactes karine

désolé pour TOI, ne fréquentes pas les milieux informatiques si tu es délicat
j'explique, j'ai pas demandé d'aide
et pas fini de corriger, comme dit!

```text sans commentaire
```text
curl --head http://kolibricoaching.net/learn/
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache
X-Powered-By: PHP/7.2
```
la version PHP n'a pas été touché depuis hier... ```

non pas une Coïncidence, y'a eu un bug hier, je reviens expliquer

PMA=PhpMyAdmin

alors pour le cas Karine:

base sur serveur mySql 5.1.73-2+squeeze+build1+1-log
la base en UTF8
**sans collation** mais sans aucune importance:
```text
wp db query "SHOW CHARACTER SET;" | grep utf8
| Charset | Description | Default collation | Maxlen |
| utf8 | UTF-8 Unicode | utf8_general_ci | 3 |
```
la collation utf8_general_ci étant celle par défaut et Wp n'imposant pas la sienne

PMA 4.0 ou mySql 5.1 n'ajoute pas les collations par défaut ce qui est le comportement d'aujourd'hui pour PMA/mysqldump ou mysql 5.5+

je n'ai pas tilté hier et je n'ai pas relevé les variables du serveur
aujourd'hui les variables du serveur sont ok
```text
SHOW VARIABLES LIKE 'char%';
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server utf8
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/

SHOW VARIABLES LIKE 'colla%';
collation_connection utf8_general_ci
collation_database utf8_general_ci
collation_server utf8_general_ci
```
symptômes apparents
```text
export en utf8: fichier ISO-8859-1
export en iso: fichier ISO-8859-1
```
les caractères dans la base sont parfaits, sauf que l'encodage ne correspond pas à ce qui est extrait (souci de config de @@CHARACTER_SET_RESULTS forcé en iso? ou serveur en iso?)

ce souci a commencé jeudi 7/03 et karine a corrigé une page pour tester
ce souci a été corrigé vendredi 8/03 dans l'AM

la résolution a donc été fait tout seule

si Ovh n'était pas intervenu, il aurait suffit de convertir en uft-8 l'export utf8/iso et le réimporter dans une base correctement configurée en utf8

* on me souffle que sur un windows, on peut faire un copier/coller dans notepad++
* sur linux, il faut convertir le fichier, le collage conservant l'information de l'encodage

ce que j'ai testé en migrant la base sur le serveur mysql5.5

### mais ...

il a quand même fallu recorriger manuellement la page que karine avait corrigée jeudi mais qui s'est retrouvée mal encodée (cette fois dans la base) quand la config est redevenue correcte

### causes possibles

donc en cas de soudaine apparition, il est **important** de déterminer l'origine du souci au risque d'empirer les choses

* passer en container.image semble être suffisant pour certain
* parfois, (j'ai eu le cas hier aussi), table correcte et encodage aussi, mais la migration avait changé l'encodage par défaut, et le script fait maison n'initialisait pas le charset uft8
* parfois, c'est le cas ici, il faut déterminer si le comportement est un défaut du serveur et réclamer du support
* parfois (cela s'en produit année dernière déjà) il faut exporter en latin1 pour réimporter en utf8: **c'est le plus simple à tenter**
* parfois, convertir l'export mal encodé avant de réimporter correctement en utf8, ce qui était une possibilité ici pour migrer correctement ailleurs
* vérifier que le `charset` par défaut soit défini dans les paramètres de connexion

bref pas UNE seule recette, **SAUVEGARDE INITIALE** et inspection fine requise

* l'export avec phpMyAdmin n'est fiable, malgré le signalement à Ovh, ce problème perdure
par sécurité, exporter plusieurs fois de suite pour sélectionner un export de taille homogène avec les autres
* export en UTF-8
* export en ISO-8859-1

en éditant ton message, c'est un coup de chance de l'avoir vu...

le changement de serveur doit être fait manuellement par l'utilisateur
(avec la migration sur Gravelines, je n'ai aucune idée de ce qu'a prévu Ovh)