Forum Programmation.php Gestion des accents dans un projet php/mysql...

Posté par . Licence CC by-sa
2
2
juin
2016

Bonjour à tous,

Avant de poser la question, je vais resituer le contexte : j'ai commencé à contribuer à un logiciel dont j'avais besoin pour mon boulot (non, je ne dirais pas lequel, non pas que ce soit hyper confidentiel, mais j'estime que ce n'est pas à moi de faire de la pub pour ce logiciel…). Comme indiqué dans le sujet, c'est un projet en PHP/Mysql qui n'a jamais pris le temps de gérer correctement le problème des accents.

Aujourd'hui, on veut s'y atteler, mais on a 2 visions légèrement différentes des choses. Le développeur principal et moi-même sommes d'accord sur le fait de tout passer en UTF-8 (base de données, fichiers PHP, entêtes HTML, etc…), mais en plus, le developpeur veut passer tous les caractères en entités HTML directement dans la base. Et là j'avoue que je suis moins chaud, surtout que je dois accéder à cette base à partir d'une application lourde en c#. En plus, même si je n'ai pas encore trouvé le cas, je crains des effets de bord (longueur des chaines différentes entre é et é, comparaison entre chaines délicate, autre ??)

Donc les questions sont : comment gérer proprement le codage des caractères dans un projet de ce type ? Existe t'il des "recommandations" plus ou moins officielles ? Bref, j'aimerais un peu ouvrir le débat et avoir des avis de "professionnels" (parce que dans le projet, nous sommes 2 amateurs…).

Merci pour vos avis !

  • # pas d'entités HTML

    Posté par (page perso) . Évalué à 10.

    mais en plus, le developpeur veut passer tous les caractères en entités HTML directement dans la base

    A moins de stocker du HTML (auquel cas cela aurait du sens), je n'utiliserais pas d'entités HTML pour stocker les caractères. L'objectif des entités, c'est de pouvoir définir des caractères "complexes" avec un jeu de caractères restreint (ascii) en faisant fi des problèmes d'encodage.

    Si les données sont en utf8, alors il n'y a pas de soucis de gestion d'encodage. Il faut simplement s'assurer que la base de données soit aussi en utf8 par défaut. Eventuellement, peut se poser la question de la normalisation utilisé pour stocker les caractères en utf8. Stocker des données normalisées permet d'éviter des effets de bord lors de recherches textuelles.

    Si de plus, la base de données est utilisée par plusieurs applications, alors là, carrément, je ne stockerai pas les caractères en tant qu'entités HTML. Pourquoi ? Plus il y a d'applications qui utilisent une même base de données, et plus il peut être nécessaire d'écrire une requête à la mano de temps en temps, pour une raison x ou y (corriger une incohérence dans les données, un problème d'interopérabilité, faire des stats, une extraction, etc…), et là, bon courage avec les entités.

    Après, ton collègue a peut être une raison précise pour vouloir cela. Mais sans raison justifiant l'utilisation des entités, je ne les utiliserais pas côté BD.

    • [^] # Re: pas d'entités HTML

      Posté par . Évalué à 1.

      Merci pour ton retour. Ca fait 1-0 pour moi !

      • [^] # Re: pas d'entités HTML

        Posté par (page perso) . Évalué à 3.

        UTF-8 a été défini en 1996 et révisé ensuite « puis finalement en 2003 (RFC 3629), cette dernière version faisant d’UTF-8 un des standards de l'internet (STD 63) »

        les entités HTML n'ont de sens que pour produire de l'HTML, l'UTF-8 est donc au moins à égalité mais à portée plus large (stockage, i18n).

        sérieux, on est en 2016 là…

    • [^] # Re: pas d'entités HTML

      Posté par . Évalué à 2.

      pas mieux que francesco

      UTF8 pour le stockage des infos,
      libre aux pplicatifs de faire ensuite usage de htmlentities(chaine en UTF8) s'ils veulent faire des URLs qui ressemblent à çà (qui se code en %eacute; %cedil;%eacute;) on est d'accord c'est illisible

      • [^] # Re: pas d'entités HTML

        Posté par (page perso) . Évalué à 2.

        Encore +1 pour Francesco.

        Les htmlentities, c'était une solution avant la prépondérance des jeux de caractères en général (et UTF-8 en particulier … mais on pourrait en utiliser d'autres).
        Dans le monde d'aujourd'hui, ça n'apporte que des soucis : ça fait longtemps que je n'en utilise plus pour les caractères accentuées (seulement pour les caractères spéciaux e.g. (c) © ).

        Il faut juste bien s'assurer de faire la déclaration d'en tête des fichiers HTML, et d'utiliser un éditeur qui gère bien les jeux de caractères (et plus spécialement le UTF-8, puisque c'est votre choix) et d'avoir un défaut qui va bien (pour la création de nouveaux fichiers … qu'on a vite fait de créer avec le mauvais jeux de caractères) … et pareil pour la base de données (en règle générale, ça se déclare au niveau des tables).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.