Affichage de caractères spéciaux

**mauyebo** · 20/11/2020, 20h23

Bonsoir à toutes et tous

les caractères accentués des textes provenant de ma base de données s'affichent avec un losange noir et point d'interrogation sauf lorsqu'ils sont codés avec (exemple) é .à la place de é
par contre les textes avec caractères accentués provenant de mes scripts s'affichent correctement.

mon serveur local : wampserver
éditeur : dreamweaver
navigateurs mozilla et IE

dans tous mes scripts avec <head> j'ai mis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta charset="UTF-8">

et dans mon fichier htaccess

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AddDefaultCharset utf-8

rien n'y change ...
si quelqu'une ou quelqu'un a une piste sérieuse elle sera bienvenue

**mathieu** · 20/11/2020, 22h41

c'est peut-être les réglages de la base de données qui sont à modifier.
regardez cet article :
https://antoun.developpez.com/mysql5/jeux-collations/

**mauyebo** · 20/11/2020, 23h40

bonsoir

23 pages à lire .. la doc ne manque pas d’intérêt. Les explications sont nombreuses . En lisant la page 4 , j'ai déjà oublié ce qu'il y avait en page 1 . Pas encore vraiment éclairé pour mon problème . Je la relirai .

Ce que j'ai pu en retenir m'a conduit à effacer puis recréer ma BD en UTF8_unicode_ci.
Le problème d'affichage des textes provenant de la BD semble avoir été résolu mais surtout avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$link -> set_charset("utf8");

que j'ai mis dans ma config juste après la connexion .
Ce qui me semble étrange c'est de devoir préciser set_charset UTF-8 à une base de donnée qui est déjà configurée en UTF-8 !!

maintenant je retrouve un problème similaire avec les retours de mes fonctions en partie concaténés avec "¤" et qui ne passent pas lorsque je souhaite les récupérer ..
la function incriminée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
function getTailleQuantite($xTaille, $xQuantite, $xValue, $xIndexTab, $xPrix, $xCoef){
	if($xQuantite > 0){
		return "<input type='radio' name='taille_" . $xIndexTab . "' value='" . $xValue . "¤" . $xPrix . "¤" . $xCoef . "'style='border-right: 1px solid #9EF776 ; border-bottom: 1px solid #9EF776'>";}
		else {
			return "<input type='radio' name='taille_" . $xIndexTab . "' value='" . $xValue . "¤" . $xPrix . "¤" . $xCoef . "' >";}
 
}

**resus** · 20/11/2020, 23h53

Bonjour
Voir ce tuto et revenir nous voir
https://j-willette.developpez.com/tu...-site-en-utf8/
Ne pas oublier de déclarer ses scripts en UTF8 sans bom
et la connexion sql avec mysql_set_charset( 'utf8' ); ou SET NAMES "utf8";

Et le cache de son navigateur s'il existe....

**mauyebo** · 21/11/2020, 17h05

Bon !!
J'ai relu jeux et collations ce matin . Jusqu'à la page 10 .. très intéressant et compréhensible . Après, c'est devenu , pour moi, un peu confus jusqu'à la .. noyade.
15 mn d'apnée, et lecture du tuto encoder-son-site-en-utf8 (plus accessible .. pour moi) . J'ai suivi à la lettre, configuré ma BD utf8_unicode_ci .

ensuite j'ai repris tous mes scripts et les ai convertis , pour ceux qui ne l'étaient pas , en UTF-8 sans cocher la case BOM . Revu les textes et remplacé les caractères qui s'étaient transformés à la conversion . Une bonne partie étaient en "Europe de l'ouest".

Lorsque j'essaie, il y a une foultitude de messages d'erreur avec la fonction preg_replace que j'utilise dans mon fichier de config qui me disent : Warning: preg_replace(): Unknow modifier 'ici le losange avec point d'interrogation" in .... . Il y a donc des caractères qu'il ne reconnait pas !!
Tous ces messages d'erreur disparaissent lorsque je remets le fichier en encodage "Europe de l'ouest". Par contre , j'ai toujours mon problème avec ce qui me revient de mes formulaires et les fonction qui sont dans mon fichier de config ... là, ça fume ...

**Paraffine** · 22/11/2020, 21h02

Bonsoir mauyebo,

En suivant les préconisations de ce billet, j'ai aussi converti (avec Notepad) mes fichiers qui apparaissaient déjà en utf-8 sans BOM et dont les caractères accentués (i.e. ceux saisis dans le fichier même) s'affichaient correctement. Et le comportement de mon application a changé (en mieux !)
Mais bon, il y avait une circonstance aggravante : rédaction des fichiers sous Windows

Pour les fichiers, lire avec attention les passages sur les doubles encodages et les guillemets.

C'est aussi plus détaillé pour les bases de données - MySQL - , mais en moins de 23 pages

, et - de mon point de vue - compréhensible : ceci pour les autres infortunés qui liraient ce fil et qui seraient bloqués à cette étape.

Enfin il y a un paragraphe à la fin sur les fonctions PHP utiles, notamment pour les flux.

Bon courage.

**CosmoKnacki** · 23/11/2020, 10h38

Warning: preg_replace(): Unknow modifier 'ici le losange avec point d'interrogation"

Si tu obtiens ce warning après conversion c'est qu'à la base tu as fait le choix d'un délimiteur pas très catholique pour ta pattern (c-à-d en dehors de la plage ASCII). Si tel est le cas, mieux vaut en revenir à un délimiteur plus classique. D'autre part, si la pattern traite des chaînes en utf-8 ou si elle contient des caractères en dehors de la plage ASCII, tu dois ajouter le modificateur u pour qu'elle soit correctement interprétée (sinon elle sera lue octet par octet au lieu de caractère par caractère).

**mauyebo** · 23/11/2020, 21h41

Envoyé par CosmoKnacki

Si tu obtiens ce warning après conversion c'est qu'à la base tu as fait le choix d'un délimiteur pas très catholique pour ta pattern (c-à-d en dehors de la plage ASCII). Si tel est le cas, mieux vaut en revenir à un délimiteur plus classique. D'autre part, si la pattern traite des chaînes en utf-8 ou si elle contient des caractères en dehors de la plage ASCII, tu dois ajouter le modificateur u pour qu'elle soit correctement interprétée (sinon elle sera lue octet par octet au lieu de caractère par caractère).

Le problème est que cela fonctionnait parfaitement avec le serveur et le script en php 5 . Peut être était-il plus permissif . le délimiteur que j'utilise est ¤ . avec ça je suis sûr de ne pas le retrouver dans les paramètres qui m'intéressent dans mes formules . Avec un délimiteur plus .. consensuel .. ça fonctionne . mais ça ne me convient pas vraiment . Sinon , que proposes-tu comme délimiteur "classique" ?
Où et comment places-tu ce "u" ?

**mauyebo** · 23/11/2020, 21h54

Envoyé par Paraffine

Bonsoir mauyebo,

En suivant les préconisations de ce billet, j'ai aussi converti (avec Notepad) mes fichiers qui apparaissaient déjà en utf-8 sans BOM et dont les caractères accentués (i.e. ceux saisis dans le fichier même) s'affichaient correctement. Et le comportement de mon application a changé (en mieux !)
Mais bon, il y avait une circonstance aggravante : rédaction des fichiers sous Windows

Pour les fichiers, lire avec attention les passages sur les doubles encodages et les guillemets.

C'est aussi plus détaillé pour les bases de données - MySQL - , mais en moins de 23 pages

, et - de mon point de vue - compréhensible : ceci pour les autres infortunés qui liraient ce fil et qui seraient bloqués à cette étape.

Enfin il y a un paragraphe à la fin sur les fonctions PHP utiles, notamment pour les flux.

Bon courage.

Salut Paraffine
J'ai téléchargé notepad++ et recopié enregistré mon fichier problématique ..(ce qui est ballot c'est que c'est le fichier config .. il est partout et tout le temps) mais , pour l'instant, .. pas de nouveau . Je vais relire ton "billet" qui, dans ma première approche, ne manquait pas d’intérêt..
à suivre

La théorie c'est quand on sait tout et que rien ne fonctionne, la pratique c'est quand tout fonctionne mais que l'on ne sait pas pourquoi. AE

**CosmoKnacki** · 23/11/2020, 22h48

¤ (CURRENCY SIGN), c'est pas étonnant. Ce caractère est encodé sur un octet xA4 en Windows-1252 mais sur deux octets (xC2 xA4) en utf-8.
Pour le moteur de regex le délimiteur est l'octet xC2, et légitimement, il se demande quel est le modificateur xA4 (qui n'existe pas).
Ça n'a donc rien à voir avec une supposée permissivité plus grande de PHP 5, mais avec l'encodage de tes scripts.

Le délimiteur que tu choisiras n'a aucune importance tant que tu évites ces caractères: . ? * + | \ ( ) [ ] { } ^ $ # < > : (car ce sont de mauvais choix) et que tu le choisis dans la table ASCII (pratiquement tout est autorisé sauf les chiffres, les lettres, les caractères blancs et le caractère NUL). Le slash ou le tilde sont de bons candidats.
Si tu veux insérer une variable dans la pattern, passe-la d'abord par la fonction preg_quote (voir le manuel PHP).

**Paraffine** · 23/11/2020, 23h49

Bonsoir,

Ce qui fait peur avec la conversion des fichiers, ce sont des cas de double encodage. Sauvegarde first.

@CosmoKnacki ; je ne pratique pas les preg_replace, du coup je suis curieuse de savoir ce que cela donnerait à ton avis en remplaçant le délimiteur litigieux par son code unicode \x{00A4} et le modificateur u ? Cela fonctionnerait sur de l'utf-8 ? Et planterait si on l'applique sur des données encodées en ASCII ? Merci de tes lumières - pardon si cette question est à coté de la plaque-.

**CosmoKnacki** · 24/11/2020, 05h19

@Paraffine: Malheureusement non, ça ne fonctionnera pas pour deux raisons:

La séquence d'échappement \x{00a0} n'est interprétée que dans le corps de la pattern (entre les délimiteurs).
Quand bien même, par exemple en utilisant à la place \u{00a4} dans une chaîne entre double quotes,, elle figurerait toujours le caractère ¤ qui est encodé sur deux octets en utf-8, or le délimiteur ne doit occuper qu'un seul octet.

Après pour pondre un délimiteur waterproof à n'importe quel ré-encodage et qui a peu de chance de rentrer en collision avec les éléments du corps de la pattern, on peut taper dans le bizarre comme des caractères de contrôle ou les octets de 80 à FF:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
// Allez hop, on va prendre EOT (End Of Transmission)
echo preg_replace("\x04Belette\x04", "Fouine", "Le Chat, La Belette et le Petit Lapin.");

mais encadrer une pattern avec une séquence d'échappement ça fait un peu lourdingue quand même.

L'ASCII c'est 128 caractères codés de 0 à 127 et la quasi totalité des encodages ont ces 128 caractères en commun, codés de la même manière, y compris utf-8.

**Paraffine** · 24/11/2020, 09h38

Merci beaucoup pour ces précisions, CosmoKnacki !

**mauyebo** · 24/11/2020, 11h43

Un mixage des infos de Paraffine et de CosmoKnacki , que je remercie au passage (entre autres) , a fait évoluer les choses .
Mon script de config était en ANSI et fonctionnait .. à peu près .. avec tous les autres scripts du site ainsi que la BD en UTF-8 . bon !! pourquoi pas !!
Lorsque je convertissais "config.php" en UTF-8 avec Notepad++ ==> message d'erreur qui ne bloquait pas tout mais faisait désordre ..
Solution du moment conseillée par CosmoKnacki, qui a fait évoluer les choses :
-Reconvertir config.php en UTF-8
-remplacer le séparateur que j'utilisais ¤ (Alt Gr $) par le tilde ~(Alt Gr é + barre d'espace) .
Exit le message d'erreur .. du moins , dans ma page d'accueil . Il me reste maintenant à remplacer ¤ par ~ dans le reste des scripts pour voir si j'arrive .. au bout .

Tout le monde est un génie. Mais si vous jugez un poisson sur ses capacités à grimper à un arbre, il passera sa vie à croire qu'il est stupide.

Affichage de caractères spéciaux

PHP & Base de données

Discussions similaires

Partager

Partager