UTF-8 est l"encodage par défaut en XHTML donc pas besoin en soi.
Ce n’est pas tout à fait vrai et c’est une situation fondamentalement
ambigue.
Déjà parce que ton XHTML est très probablement envoyé en tant que
text/html et pas en tant que application/xhtml+xml. Du coup le moteur
n’a
à respecter que les règles HTTP et HTML. Bref, dans ces cas là ce qui
prime c’est la présence du codage caractère dans l’entête Content-Type.
A défaut de spécification explicite c’est de l’ISO-8859-1 (le défaut HTTP)
et pas de l’UTF-8 qui devrait être lu.
Bref, si rien n’est explicite dans l’entête HTTP et qu’il utilise une
déclaration text/html il fait très bien de déclarer le jeu de caractères
dans le prologue.
Et même dans le cas d’un document envoyé en tant que xhtml/xml, c’est
finalement ambigue. La norme XML nous dit :
“”“In the absence of information provided by an external transport
protocol (e.g. HTTP or MIME), it is a fatal error […] for an entity
which begins with neither a Byte Order Mark nor an encoding declaration
to
use an encoding other than UTF-8. Note that since ASCII is a subset of
UTF-8, ordinary ASCII entities do not strictly need an encoding
declaration.”“”
Bref, si tu as un bête fichir sur disque, le codage par défaut est bien de
l’UTF-8. Par contre si tu passes sur HTTP, il y a bien une information
de
codage fournie par la couche transport (soit explicite, soit implicite
c’est à dire de l’iso-8859-1) donc tu as le droit d’utiliser un autre
codage que l’UTF-8 sans le spécifier dans le doc XML. Et pas réciprocité
si tu ne spécifies rien et que tu es en HTTP, un moteur pourrait
interpréter la norme en disant “mon xml est en iso8859-1”.
Je disais ambigue parce que la question est de savoir si un codage
implicite (par défaut) est considéré comme “provided by” ou pas.
Bref, même envoyé en application/xhtml+xml il vaut mieux utiliser une
déclaration de codage caractère dans le prologue. Ca a le mérite de lever
tout problème.
Didier, peux-tu nous soumettre une partie du code de ton controleur et
de ta vue ?
Il semble que cela soit lié à l’OS … Je réessaie chez moi et que ne
constaté-je point la disparition des termes “heure d’été” !!!
Ici j’ai un Windows XP Pro en français.
La conclusion : j’abandonne les OS en français et surtout Windows
(quelle que soit la locale) ! Cet OS est épouvantable. Enfin quand je
dis “j’abandonne”, euh … je vais essayer d’abandonner
Concernant les pistes évoquées:
Thibaut : aucun RJS ou AJAX, même pas de trace de “8859” dans aucun
fichier du projet
Bastien : DB ok, en UTF-8
Zambra : quel lien entre les données créées par l’application en
utilisation et l’IDE ayant servi à créer cette application, là je pige pas !
In fine, je rejoins l’hypothèse d’Olivier sur la “locale” comme la plus
vraisemblable dans le cas présent. Mais j’essaierai les déclarations de
Matthieu dès mon retour au bureau demain. Si ça marche je vous tiens
informés.
Merci à tous,
et à bientôt donc pour mes prochains déboires … sous Linux !
before_filter :set_charset
def set_charset @headers[“Content-Type”] = “text/html; charset=iso-8859-1”
end
Mathieu C. wrote:
Je crois me souvenir, et d鳯lé °as le temps de tester :
J’ai ajouté ¬’encoding ici, pour que celà °asse avec IE + Webrick
<?xml version="1.0" encoding="UTF-8"?>
Firefox n’en avait pas besoin. Il utilisait s?nt la d飬aration du
meta plus loin.
Sous apache j’utilisais AddDefaultCharset utf-8 dans mon VHOST, mais
il me semble que ç¡ n’avait pas d’effet vu que les entè´¥s é´¡ient
déª bien renseign饳, mais sert toujours pour les pages statiques.
Et cerise confite sous IIS il fallait aussi faire une bidouille pour
que ç¡ passe avec IE.
Je crains de ne plus voir assez clairement mon code. Ou il y a un
truc que je n’ai pas saisi mais j’ai vérifié sur 150 sources et j’ai
l’impression de ne pas m’être
trompé.Est que quelqu’un voit une erreur là-dedans :
Je crois me souvenir, et désolé pas le temps de tester :
J’ai ajouté l’encoding ici, pour que celà passe avec IE + Webrick
<?xml version="1.0" encoding="UTF-8"?>
Firefox n’en avait pas besoin. Il utilisait sûrement la déclaration du
meta plus loin.
Sous apache j’utilisais AddDefaultCharset utf-8 dans mon VHOST, mais
il me semble que ça n’avait pas d’effet vu que les entètes étaient
déjà bien renseignées, mais sert toujours pour les pages statiques.
Et cerise confite sous IIS il fallait aussi faire une bidouille pour
que ça passe avec IE.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
