Problème d'accent lors de la mise en ligne

PHP HTML MYSQL

Le problème exposé dans ce sujet a été résolu.

Bonjour à tous, je demande votre attention pour m'aider sur un problème très récurrent que j'ai vu sur énormément de forums mais je n'arrive toujours pas à le résoudre.

Pour mon projet d'ISN (épreuve du bac), j'ai dû créer un site internet (site de vente). Malheureusement j'ai des problèmes d'accents entre le PHP et le HTML, du moins quand je passe mon site en ligne (en local tout va bien). Par exemple lorsque je crée un article et que je l'envoie dans ma base de donnée il s'écrit mal et les articles ont ensuite plein de "?" dans leur titre et description à la place des accents.

J'ai créé mon site avec le charset: iso-iso-8859-1, car avec l'UTF-8 il y avait encore plus de problèmes. J'ai essayé de mettre ma base de données en latin1_general_ci et en UTF-8 mais ça ne change rien. Voilà le lien de mon site si vous voulez aller le checker: http://airtech.esy.es

Si vous avez besoin d'informations pour m'aider à résoudre mon problème je peux vous envoyer des morceaux de mon code.

Le site est inaccessible, je suppose que tu fais des testes.

Quand tu as le choix, essaye au maximum d'utiliser l'utf-8. On ne peut même pas écrire correctement en français en Latin1.

+0 -0

Salut j'ai passé tout mon site en UTF-8 grâce à l'encodage de notepad++ et ma base de donnée également. Cependant un nouveau problème viens d’apparaître, lorsque je rentre un texte avec des ' ou des " il ne s'affiche pas correctement à la place j'ai des ' ou des 5,5' . J'ai supprimé les ENT_QUOTES UTF-8 pour résoudre le problème des ' et là c'est bon mais les guillemets ne marchent toujours pas et maintenant j'ai des " . L'encode commencer vraiment à me gonfler avez-vous des solutions?

Ca ne peut même pas être un problème d'encodage tout court sur une quote puisqu'elles sont strictement codées de la même façon sur tous les jeux de caractères qui agissent comme un sur-ensemble d'ASCII (c'est notamment le cas des ISO-8859-1(5), CP1252, UTF-8, etc).

Me revoilà désolé de pas avoir répondu mais il y avait un problème de connexion sur le site avec les comptes google. C'est le traitement d'un titre d'article:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<?php
if (isset($titre_article)) {
    $titre_article = htmlspecialchars($titre_article);//Si il y a un titre
    if (!preg_match('#^.+$#',$titre_article))
    {
        $validation = 1;
        $erreur = 'METTRE UN TITRE';
    }
}
else
{
    NULL;
}
?>

Et là quand je l'affiche

1
<?php if(isset($produit['titre'])){echo htmlspecialchars($produit['titre']);}else{echo "Article introuvable";}?>

Donc ça fait bien 2 htmlspecialchars au lieu d'un ? Pas lieu de faire un htmlspecialchars avant ta regexp, c'est seulement pour l'affichage.

Tes extraits ne sont pas partinents, ils ne sont pas assez longs et sortis de leur contexte. Tu fais un htmlspecialchars avant l'INSERT (quand il ne faut pas) mais également suite au SELECT ?

HS :

  • if (!preg_match('#^.+$#',$titre_article)) : ce ne serait pas plus simple d'utiliser !empty ou un (mb_)strlen ou c'est parce que tu comptes faire quelque chose de plus strict par la suite ?
  • ton instruction NULL; ne sert à rien (donc le else aussi par extension si c'est sa seule instruction)
+0 -0

Dac merci je suis débutant en PHP c'est gentil de me corriger, le regexp c'est pour vérifier si le champs et remplis et ainsi avertir l'utilisateur car je n'utilise pas de javascript et c'est le seul moyen que j'ai imaginé. Donc pour le htmlspecialchars il faut pas le mettre avant l'insertion dans la bdd? Pourtant sur OCR ils insistent beaucoup là dessus. Merci pour vos réponses.

+0 -0

Pourtant sur OCR ils insistent beaucoup là dessus. Merci pour vos réponses.

Quel cours au juste ? Dans le tuto officiel php/mysql, a priori, ce n'est pas dit explicitement mais htmlspecialchars n'est utilisée que pour l'affichage.

Si, il faut le mettre dans le insert, mais pas dans le select vu que cela a déjà été fait lors de l'insertion de l'article en question dans le bdd.

T'as absolument rien compris alors. Ca va te servir à quoi de htmlspecialchars/htmlentities à l'insert ? Dénaturer inutilement tes données dont les conséquences sont, entre autres :

  • les rendre inutilisables pour les recherches ? (plus difficile de chercher &amp; que & et je ne parle même pas de ton interclassement *_ci qui ne sert plus à rien avec htmlentities : É = ê = E mais &Eacute; != &ecirc; != E)
  • consommer au moins 4 fois plus de place pour stocker un caractère ? (&amp; = 5 caractères, & = 1)
  • les rendre inutilisables pour un autre format que HTML en sortie ? Tu dois d'abord faire un html_entity_decode ou équivalent pour pouvoir travailler dessus ? Que de travail inutile !

Quid aussi de ce qui ne transiterait pas d'abord par la base de données ou ce qui aurait été inséré sans passer par ton site : XSS garantie ?

+0 -0

Ah, désolé, j'avais confondu avec la fonction permettant d'éviter les injections SQL (mysqli_real_escape_string) qu'il faut par contre bien faire sur les arguments concaténés aux requêtes SQL.

victorlevasseur

Mouais… Mieux vaut encore utiliser les requêtes préparées, à mon avis. Ça a été pensé pour éviter d'avoir à réfléchir à sécuriser avant de concaténer, aussi.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte