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

PHP HTML MYSQL

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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.

+0 -0

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.

ache.one                                                                                   🦊

+0 -0
Auteur du sujet

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?

+0 -0

Code ? Parce que tu fais deux fois un htmlentities/htmlspecialchars ? Du moins, au moins un quand il ne faut pas ?

En tout cas, ça (ces entités HTML), ça n'a rien à voir avec l'encodage …

Édité par vibrice

+2 -0

En tout cas, ça (ces entités HTML), ça n'a rien à voir avec l'encodage …

vibrice

En effet, si c'est un problème d'encodage, les caractères sont remplacés par des carrées, losanges ou points d'exclamation. Et non par les entités HTML.

Édité par A-312

+0 -0

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).

+0 -0
Auteur du sujet

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";}?>
+0 -0

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)

Édité par vibrice

+0 -0
Auteur du sujet

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.

Édité par Airox

+0 -0
Auteur du sujet

D'accord merci je vais essayer je vous tiens au courant.

EDIT: C'est bon ça marche très bien je vous remercie énormément !

Édité par Airox

+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 ?

Édité par vibrice

+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.

Édité par victorlevasseur

+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.

Édité par Ymox

Evitez qu'on vous dise de les lire : FAQ PHP et Symfony 2Tutoriel WAMP • Cliquez 👍 pour dire merci • Marquez vos sujets résolus

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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