Forum LinuxFr.bug Problème d'encodage dans les articles.

Posté par .
Tags : aucun
1
26
avr.
2009
Tout d'abord j'aimerais signaler que je suis au courant qu'il y a une partie "Suivi de bug" sur le site mais ayant peur de le polluer avec des informations erronées, je préfère poster ici avant.

Donc sauf grossière erreur de ma part, LinuxFr est encodé en UTF8.

Dernièrement j'ai remarqué 2 articles qui avait un défaut d'encodage dans la https://linuxfr.org/my/>liste des articles, alors qu'ils apparaissent bien lorsqu'on les affiche en entier, à savoir l'article sur LinuxDays 2009 à Genève - 3, 4 et 5 juin et celui sur La forge des plugins Sonar est opérationnelle.
Reproductible sur firefox3 et konqueror 4.2.

- Dans le premier cas, dans la phrase "cela comprend également l'opportunité", le é d'opportunité est encodé EF BF BD (3octets en UTF8 ??)
- Dans le deuxième cas on retrouve la même erreur sur le é de fonctionnalité dans la phrase "Autour de ce cœur viennent se greffer des plugins qui contiennent les fonctionnalités"

Je ne sais pas trop d'où cela peut bien venir. J'ai trouvé ça si ça peut aider à tout hasard :
http://www.stylusstudio.com/xmldev/200306/post10460.html


D'autres personnes ont-ils constaté la même chose ?
  • # Coupure du texte

    Posté par . Évalué à 4.

    Le fait que cela concerne toujours le dernier mot me fait penser à une coupure du texte à une longueur fixe en mode binaire, et donc sans tenir compte de l'encodage.
    Résultat: la coupure intervient au milieu d'un caractère UTF8...

    Si vous n'aimez pas ce commentaire c'est qu'il est ironique.

  • # error 404

    Posté par . Évalué à 2.

    chez moi les 2 pages cités en exemples n'existent pas à partir de ton post

    et j'ai bien l'erreur dans le
    http://linuxfr.org/my/

    mais comme le dit si bien Ymge, cela semble du à la limite d'affichage des sujets dans le mode "my".

    le post est donc coupé sauvagement au milieu d'un mot, voire d'un caractere

    une solution pourrait etre de reduire le volume de cette partie du texte (dans l'editeur de depeche) afin de ne pas avoir à tronquer

    et de mettre la suite dans le 2e bloc de l'editeur de depeche
    • [^] # Re: error 404

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

      chez moi les 2 pages cités en exemples n'existent pas à partir de ton post

      elles existent pourtant bien
      http://linuxfr.org/2009/04/25/25360.html LinuxDays 2009 à Genève - 3, 4 et 5 juin
      http://linuxfr.org/2009/04/20/25329.html La forge des plugins Sonar est opérationnelle

      mais àmha, une bonne solution serait de tronquer correctement ;-) (donc sur des mots complets, le reste étant du contournement qui a ses limites). Par exemple, les dépêches de seconde page et celles de première page ne sont pas tronquée de la même manière, or cela ne peut être su qu'à validation de la dépêche, pas à sa soumission.
    • [^] # Re: error 404

      Posté par . Évalué à 2.

      oui, bien vu de la part de Ymage, ça semble être ça.

      Pour les liens morts, je ne connais rien en html et j'avoue avoir un peu galérer à les faire. Ceci dit à la fin il marchait enfin correctement dans le mode preview, donc là c'est balo ...
  • # Point de détail

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

    3octets en UTF8 ??

    C'est tout à fait possible, l'utf8 est en encodage à taille variable, un caractère UTF8 peut atteindre 8 octets en théorie, en pratique la norme impose plutôt une limite à 4, cf UTF8
    • [^] # Re: Point de détail

      Posté par . Évalué à 2.

      ah merci pour l'information, j'avoue ne pas m'être trop posé la question pour les langues non latines.

      Un autre point que je ne connaissais pas et qui est décrit sur l'article wikipedia dans la section Avantages, paragraphe Fiabilité :
      Il s'agit d'un codage auto-synchronisant (en lisant un seul octet on sait si c'est le premier d'un caractère ou non).

      Si ce que dit Ymage est exact, et en dehors de la coupure du texte mal faite, il semble que le coté "auto-synchronisant" de l'UTF-8 ne soit pas respecté ici, si ?
      • [^] # Re: Point de détail

        Posté par . Évalué à 1.

        Si ce que dit Ymage est exact, et en dehors de la coupure du texte mal faite, il semble que le coté auto-synchronisant de l'UTF-8 ne soit pas respecté ici, si ?
        Tout à fait.
        Auto-synchronisant, encore faut-il manipuler la chaîne en tenant compte de l'encodage...
        Ici, ça sent le simple substr() (en PHP) qui ne fonctionne qu'en mode octet contrairement à mb_substr() qui raisonne en caractères, potentiellement multi-octet.

        Si vous n'aimez pas ce commentaire c'est qu'il est ironique.

Suivre le flux des commentaires

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