Problème caractères accentués depuis ce matin !

Bonjour,

J'ai le même problème sur mon Forum depuis ce matin !

J'ai des points d'interrogation à la place des caractères accentués...

Bonjour @SYLVAINR12 et @SilverFlag ,

Pourriez-vous préciser le nom de domaine impacté?
Avez-vous changé votre image de legacy à stable récemment (ou l'inverse)?

Cordialement,

Julien

Bonjour @JulienD7,

Voici un exemple des sites sur l'hébergement... Le footer est généré à partir d'une BDD et tous les caractères accentués sont HS.
https://www.1lyon.fr/lyon.fr/

J'ai eu un problème il y a 25 jours avec des requêtes PHP et je suis passé en stable... mais OVH a patché et je suis repassé illico en Legacy.

Merci !

SR

@SYLVAINR12,

Est-ce que le fait de passer en stable à nouveau résoudrait votre problème?

Le conteneur legacy est en latin1 par défaut tandis que le conteneur stable est en utf8.

Julien

Je teste et je te dis ça ;)

De mon coté, je n'ai rien touché.

J'ai regardé dans le manager, je suis sous php 5.6 en Legacy.

J'ai essayé de passer en stable, c'est la même chose.

Bonjour

essayes de modifier cette ligne :
```

```
par

```

```

EDIT : Si ça ne fonctionne pas, regardes dans ta base de données via phpmyadmin comment apparaissent les caractères spéciaux.

Cordialement,
Boris.

@JulienD7,

Aucun changement sous Stable... Du coup retour à Legacy.

:/

```text > essayes de modifier cette ligne : ... charset=iso-8859-1

la meta html n'a pas le priorité sur le header du serveur

```text
curl --head https://www.urgences-veterinaires-lyon.fr/
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
```
pour tester, utiliser affichage/encodage du navigateur

---
ta base est mal enregistrée (avec un mauvais encodage) et retourner à legacy n'est pas la solution

par sécurité, tu pourrais peut-être télécharger une sauvegarde de plus de 25jours, si potentiellement exploitable

moi je regarderais à passer en stable, tout en utf8, conversion de la base en utf8 si besoin.
si c'est la base d'avant 25 jours, ça pourrait le faire
sinon, correction des caractères mal encodés

c'est scabreux mais je connais pas de recettes tout prête ```

Bonjour à tous,
SYLVAINR12 et SilverFlag, cette situation n'est pas normale. Ne touchez pas à votre conf, si ça fonctionnait avant, ça doit fonctionner maintenant. On regarde ce qu'il se passe…
Mikaël

Bon ben là c'est 90plan en rade de toute façon LOL

Halala... :)

http://travaux.ovh.net/?do=details&id=35499 => Roll-back de l'intervention de ce matin.

Les caractères accentués sont revenus chez moi.

Le problème semble donc résolu de mon coté !

Merci ! :)

Idem chez moi, tout est en ordre niveau accents...!

Merci !

Bonjour. Pour info, j'ai eu le même problème aussi aujourd'hui, et l'affichage correct est de retour ce soir (sans avoir rien changé de mon côté).

Même problème sur www.billouttes.be depuis quelques jours. Vu que je n’ai plus rien modifié depuis au moins 6 mois...

Même problème sur mon forum depuis jeudi matin sans que je n'aie rien changé depuis plus de 6 mois.
Le problème revient de façon aléatoire, parfois l'affichage est correct, parfois des messages sont invisibles, et réapparaissent au rafraichissement de page.
J'ai ajouté "AddDefaultCharset UTF-8" en tête de mon .htaccess racine mais sans résultat.

Après les losanges noirs avec point d'interrogation et les "î", "'é" ou "ç", voilà que maintenant les "é" sont remplacés par des "�". Enfin certains, sur la même page d'autres s'affichent correctement...

Aucune réponse à ma demande d'assistance non plus...
C'est désespérant.

Tu as un lien vers le forum...?

Edit : l'assistance OVH, c'est un fake... le formulaire n'aboutit nulle part ! ;)))

Même problème ici depuis des jours, on a une demande d'assistance en cours depuis plus d'une semaine. On tourne en rond, l'assistance donne l'impression de ne pas savoir où elle va. Pour chaque relance on a le droit à "une maintenance est en cours".

Bonjour,
Après un mois d'attente, une réponse est arrivée disant ceci :
> je vous invite à passer en mode **stable** dans votre hébergement :

> https://docs.ovh.com/fr/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/

J'ai suivi ces instructions.
Il semble que le problème soit maintenant réglé !
Demeurent quelques erreurs sur les caractères accentués de messages plusieurs fois modifiés, mais rien de bien important...

Bonjour, même problème depuis la migration vers Graveline. Aucune réponse du support. C'est bien agréable.

De rien !
Le problème que j'avais rencontré est définitivement réglé, plus aucun problème depuis mon message du 9 janvier !

Tiens c'est marrant ca parce que le support me dit de contacter un professionel du web alors que je vois qu'il y a des gens qui ont les mêmes problèmes que moi depuis le passage vers Graveline....
Donc le support me pipotte on est d'accord. J'ai pas touché a ma base ni a ma conf et pouf ca a l'air d'être de ma faute... Online.net ? Amen ? 1&1 ?un conseil ?

Pareil des caractères de type � sont apparus comme ça sans rien avoir touché, je suis en php 7.1 stable
J'ai pas envie de bidouiller des rustines du style utf8_decode, utf8_encode. Ce serait bien que les sites fonctionnent normalement.

au fait je suis sur le 015

avant de savoir à qui s'en prendre il faut analyser
mais là tu ne donnes aucun élément

tu as été migré dernièrement?

oui migré depuis quelques jours je suis sur le 015

l'encodage par défaut à changé, UTF8 maintenant
il faut donc corriger tes scripts
normalement ton CMS devrait savoir gérer

regarder le serveur Sql utilisé, son status si possible, l'encodage réel de la base (de la sauvegarde et non l'encodage revendiqué...)

Je vois cela
SET NAMES utf8mb4

seul ça ne veut rien dire
il faut aborder ça un peu plus en profondeur

-- phpMyAdmin SQL Dump
-- version 4.7.3
-- https://www.phpmyadmin.net/
-- Version du serveur : 5.6.42-log
-- Version de PHP : 5.6.38-0+deb8u1

les accents apparaissent bien dans la sauvegarde et dans la base

ce n'est pas une démarche rigoureuse de travailler par morceaux comme ça, les entêtes n'ont pas d'importance
je t'ai donné TOUTES les pistes, à faire en UNE fois, ce n'est pas une messagerie instantanée ici, mais un forum

ton fichier en encodé en quoi?
tu as demandé quel encodage à l'export?
les deux coincident?

tu peux tester en utf8 et en iso pour comparer

Si cela peut aider quelqu'un.
J'ai réglé mon problème en ajoutant au script de connexion et tout est rentré dans l'ordre.
bye

mysqli_set_charset($con,"utf8");

le charset par défaut:

* mysqli_set_charset()
https://www.php.net/manual/fr/mysqli.set-charset.php
* PDO: Ajoute le charset à la chaîne de connexion, par exemple charset=utf8
new PDO("mysql:host=localhost;dbname=DB;charset=UTF8");
https://www.php.net/manual/fr/pdo.construct.php

Bonjour,
La solution proposée ne m'apporte rien :
J'ai des pages (plusieurs centaines) codées en ISO qui s'affichent correctement sur un serveur Free perso et auparavant sur OVH.
Je viens de m'apercevoir tardivement que mes pages OVH sont toutes dégradées pour les caractères accentués comme indiqué sur ce forum. J'ai le META avec charset ISO.
Mes pages sont trop nombreuses et anciennes pour être ré-encodées UTF8, mon CMS n'est plus modifiable (outil perso)
Existe-t-il un paramétrage chez OVH pour afficher correctement des pages encodées ISO ? Dois-je considérer que l'UTF8 est obligatoire sur OVH (dans ce cas, je vais chercher ailleurs ....) ?
Pourtant, je n'ai pas sale caractère !

> J'ai le META avec charset ISO.

on ne parle pas de ça ici , on parle de base

> Mes pages sont trop nombreuses et anciennes pour être ré-encodées UTF8,

si, un éditeur un peu évolué te le fait, ou en ligne de commande

> considérer que l'UTF8 est obligatoire sur OVH

non, encore faut-il paramétrer comme il faut ton CMS

Merci pour votre réponse mais je ne demande pas comment paramétrer mon outil (pas de CMS au sens habituel), ni comment utiliser Notepad (ou autre éditeur) ou faire un script PHP, bash etc., mais simplement si on peut afficher désormais ISO-8859-1 chez OVH.
C'est la seule question simple. Je pense que ce n'est plus possible (?)

> simplement si on peut afficher désormais ISO-8859-1 chez OVH.

non car ce n'est pas de leur ressort, pour les fichiers

> ce n'est plus possible

n'a jamais

Bon, je me réponds à moi-même (!)
Les pages étaient affichées correctement il y a quelques mois (je n'ai pas fait de vérif cet été) et ce depuis au moins 2 ans.
Si je teste avec une page en html (pas de php) codée en ISO-8859-1, l'affichage est correct !
Je cherche donc coté php ....

Finalement, je viens de trouver la solution.
La configuration d'un codage par défaut sur le serveur n'est pas une obligation puisque la page web peut indiquer avec la balise META son choix. Mais si un codage par défaut a été mis côté serveur, c'est lui qui prévaut sur tous les autres choix (méthode .htaccess ou balise META)
Il faut donc imposer le charset au niveau de l'entête envoyée par le serveur.
Il suffit de mettre simplement en première ligne :


.PATH_SEPARATOR .$_SERVER['DOCUMENT_ROOT']
.'/include/'); ?>

......
......

Ceci permet d'utiliser toutes vos pages codées en ISO-8859-1 en gardant à l'esprit que le codage UTF-8 est à prendre dès que possible (si possible).

> charset=windows-1252

aie les yeux...
et si tu laissais le **DÉFAUT**, standard et universel ISO-8859-1?
tu n'aurais pas besoin de l'imposer pour rien dans un header()

Pourquoi aïe les yeux ?
Le standard universel est maintenant **UTF-8**, c'est le nouveau **DEFAUT** en version stable chez OVH ! la version précédente était ISO-8859-1. Je n'avais pas de problème auparavant parce l'ancien DEFAUT me convenait (!).
80% des serveurs sont désormais en UTF-8 et le W3C conseille vivement de l'utiliser.
L'autre solution, coté administrateur, était de ne pas mettre de charset par défaut, ce qui pose un problème pour les pages ne comportant pas de META charset.
Voilà .... ça évolue

> version précédente était ISO-8859-1.

oui, et c'est **toujours le charset par défaut des serveurs Ovh** (voire apache?)

donc ce n'est pas windows-1252

windows-1252 = ISO-8859-1
On conseille d'écrire charset=windows-1252 plutôt que charset=ISO-8859-1 (cf W3C)

> windows-1252 = ISO-8859-1

arf...
lecture simple:
> Windows-1252 est une extension de l'ISO/CEI 8859-1 : il diffère du codage ISO-8859-1 par l'utilisation de caractères imprimables,

https://fr.wikipedia.org/wiki/Windows-1252

> (cf **W3C**)

bis arf, et si tu citais tes sources?

J'arrête ici cette discussion, merci de m'avoir mis sur la piste avec le curl.
A ce sujet, il y a ce moyen du W3C :
https://validator.w3.org https://validator.w3.org
Bonne soirée

le validator, très ancien, ne vérifie qu'une syntaxe
et ne concerne donc pas le sujet des encodages

Bonjour @BenoitL68


Avez-vous une adresse de page montrant ce problème de caractères accentués ?