Cite et caractères spéciaux - Page 1

Vu qu'on a toujours des problèmes quand on utiliser Sauver/Insérer les citations sauvées, je voulais savoir si tu (yAro) avais essayé en spécifiant un encodage dans la balise script...
Perso, j'ai résolu tous mes soucis d'encodage en déclarant le js de cette façon :

<script language='javascript' type='text/javascript' charset='utf-8'><!--
--></script>

ou
<script language="javascript" src="monjs.js" type="text/javascript" charset="utf-8"></script> (ou le charset correspond bien entendu à celui de ma page).

(ah, le marronnier du bug des citations inline )

Et c'est dommage, chaque fois je défonce les posts de ceux qui font l'effort de poster avec des jolis caractères bien français (guillemets et autres)...


edit -> je ne dis pas que je m'en foutrait si ça déformait les chiffres arabes hein !

oh viiiii!

Comme je ne connais pas vraiment la portée du bug, qqun pourrait vérifier s'il est résolu (cf. ici) ou non svp ?

J'ai noté hier que les guillemets étaient citées correctement. Après, je ne m'y connais pas assez en unicode et charset pour faire de vrais tests ...

allons y

ㅂㅈㄷㄱ쇼ㅕㅑ

edit inline ajout de ㄷ&#xC58F;

ha bah c'est marrant, l'edit inline n'a cassé que ce que j'ai ajouté après.

ie, les entities sont bien reprises, par contre les nouveaux caractères a la noix, non ^^

re-edit : ㅂㅈㄷㄱ&#xC1FC;ㅕ


rere: &#xD130;ㅗㅇㄹ&#xD749;&#x313F;&#xD74B;ㅇㄹ&#xD734;ㅗㅇㄹ&#xD749;&#xB18D;&#x314E;&#xCE04;ㅗㅇㄴㅀ&#xCEE4;&#x314F;ㅗ

donc en fait, j'édite inline, je clique valider, ça sort bien, je rafraichis avec F5, c'st tout pété.

citation d'unicode

squalyl (./11) :
ㅂㅈㄷㄱ쇼ㅕㅑ

alors non seulement l'édit inline est pété si on ajoute de l'unicode uniquement, mais la citation est salement pétée

y'a une légère couille
topics/150073-tesuto/2#30

je crois que ça le faisait pas avant

Pourquoi citer fait-il apparaitre des codes de caractère comme « &#12610; » et pas le vrai caractère ? C'est stocké comme ça en base de données ou c'est une conversion qui est réalisée pour l'affichage ?

Tout ne peut-il pas être fait en UTF-8 (ou le codage que tu veux) de bout en bout avec le stockage dans le même format, de façon à ne plus avoir à faire de conversion ?

Faut que j'aille regarder comment c'est enregistré en base, mais y'a moyen que ce soit un pré-traitement sur le post qui soit effectué dans le cas d'un envoi "normal" et pas dans le cas d'un edit inline.

Il faudrait recoder toute la BDD en UTF-8 (et aussi changer le charset déclaré de toutes les pages PHP), ce que yAro n'a pas retenu une solution viable, c'est pour ça que le hack avec les codes de caractère a été introduit.

ouais, sinon tu vas !kb yaronet!

Kevin Kofler (./18) :
Il faudrait recoder toute la BDD en UTF-8 (et aussi changer le charset déclaré de toutes les pages PHP), ce que yAro n'a pas retenu une solution viable, c'est pour ça que le hack avec les codes de caractère a été introduit.

Coût de la mise en oeuvre ? => des heures de travail (et le fait que ce soit fait sur du temps libre n'y change rien)
Danger de la mise en oeuvre ? => régressions, nouvelle recette complète nécessaire, potentiels problèmes de parseur
Avantage de la mise en oeuvre ? => si jamais un groupe de zorblaxiens arrive sur yn et décide de n'utiliser que l'édit inline, certains utilisateurs auront peut etre des problèmes d'affichage...

Le hack actuel a aussi d'autres inconvénients:[ul][li]Certains navigateurs ne convertissent pas automatiquement les caractères inconnus en séquences &#, c'est un comportement spécifique à IE qui a été recopié par d'autres navigateurs, mais ce n'est pas du tout spécifié par les standards (sauf peut-être maintenant dans le HTML 5 où certains "hacks de compatibilité" ont été documentés, à vérifier). Par exemple, Konqueror ne faisait pas ça au départ, mais ça a été rajouté depuis pour la compatibilité avec IE.[/li][li]Si on veut écrire la séquence litérale pour un caractère Unicode, le parseur le prendra pour le caractère Unicode lui-même. Il n'a d'ailleurs aucun moyen de savoir si l'utilisateur a rentré le caractère ou la séquence. (C'est bien pour ça que le comportement non-standard des navigateurs dont dépend ce hack est pourri.)[/li][li]Ce bogue de Konqueror avec les caractères non-BMP n'est toujours pas corrigé, il ne touche que les séquences &# et pas l'UTF-8.[/li][/ul]Aucun de ces problèmes ne se produirait si l'UTF-8 était utilisé à la place de ce hack. Et le deuxième en particulier touche tous les navigateurs (c'est un défaut inhérent à cette méthode inventée par IE de transmettre les caractères hors charset).

Ouais, mais ça ne prouve pas que ce serait rentable de passer trois siècle à tout refondre pour ça...

Ouais nan mais le coup de la base UTF-8 il va falloir oublier

Autant ça aurait effectivement été mieux de le faire dès le départ, autant maintenant il y a tellement de risques à faire ça que c'est vraiment très bas dans la liste des priorités.

on peut pas faire une nouvelle colonne dans la table des posts, avec un default 0 pour les trucs déja présents et une valeur 1 pour les nouveaux posts (ou ceux qu'on édite), qui les signalerait en UTF-8?

C'est pas la BDD le problème (on pourrait tout à faire convertir tous les posts au fil de l'eau), c'est tout le code qu'il faut modifier pour traiter des chaines UTF-8.

ah ok

Ben disons que si tu refais un yN from scratch...

mais bien sûr

yntootoo

Han un fork fork