Problemes avec Character Set

[laurent]

Nous développons actuellement un genre de portail, comme un webtop…
Après le premier load de la homepage, toute la navigation se fait par
des requêtes Ajax.

Tous fichiers source du projet sont stockés dans un dépôt subversion :
le dépot a un jeu de caractères UTF-8.
A l’origine, notre base de données était elle aussi positionnée à UTF
8.
Récemment, notre administrateur a déplacé les données vers une autre
instance Oracle en ISO-8859-15.

Désormais, après tests de l’application, tous mots
accentuésprovenant de la base ne sont pas bien rendus dans notre navigateur.
Nous avons commencé par positionner un pré-filtre pour tous les param
entrants (envoyés par un form_remote_tag par exemple), les
convertissant d’utf-8 en ISO 8859 15 avant sauvegarde en base.

Pour la sortie : en alignant l’encoding du navigateur sur ISO, ces
caractères accentués provenant de la base sont bien affichés.
On a donc, commencé par créer un Post Filtre, forcant le character set
du Header de la réponse vers ISO…ok pour les données accentuées en
base, seulement toute notre navigation (Ajax, avec Prototype, ne
fonctionne plus…Prototype ne gèrant que de l’UTF 8)

Une autre idée était de convertir tous fichiers source du SVN en ISO
(comme la base de données) puis créer un post-filtre aui convertit
tout le contenu en UTF 8 avant envoi au navigateur (un peu comme on le
ferait avec en gzip de la réponse).

Une autre idée, plus couteuse, serait de convertir toutes données
venant de la base de données en ISO vers UTF8 (dans les controller,
voir dans les partials)

Quelle peut être la meilleure approche ? (si vous pensez comme moi le
‘repasser la base de données en UTF8’, svp ne pas répondre nous ne
pouvons pas. En effet, la base de données est utilisée par une autre
application C/S plus ancienne nécessitant cet encodage ISO)

Laurent

[laurent]

J’ai déja rencontré de pareils problèmes, l’idée va être de jouer avec
les respond_to, le soucis viens du fait que l’entête renvoyée au
navigateur lors d’un appel RJS n’est plus la bonne…

Je te met l’URL de la discussion, comme ça tu auras toutes les infos

http://www.developpez.net/forums/showthread.php?t=383572

PB

Laurent wrote:

Nous d�veloppons actuellement un genre de portail, comme un webtop…
Apr�s le premier load de la homepage, toute la navigation se fait par
des requ�tes Ajax.

[laurent]

Les joies de la vie d’entreprise… Loi du Kiwi N°1: plus c’est pourri,
plus
c’est répandu.

Une seule instance d’un serveur Oracle, pas fichuz de gérer plusieurs
charsets pour des schémas de données différents, et bloqué dans un
charset
vieux et moisi par… une application néhandertalienne (“nan, mais oh!
Elle
marche ma vieille appli!”, oui c’est comme les 4L: ça roule encore, mais
qu’est-ce que ça pollue!). Je suppose qu’il n’y a pas moyen d’avoir une
deuxième instance d’Oracle, où UTF-8 sera seul mettre à bord du navire
des
charsets, alors je ne peux que te suggérer de tenter d’imposer un
serveur
MySQL: ils bloquent bien une instance Oracle pour une et une seule
application, pourquoi ne pas bloquer un serveur MySQL pour toutes les
autres?

Dernière solution: changer de boîtes, envoie moi ton CV

Le 07/08/07, Laurent [email protected] a écrit :

[laurent]

Certes, l’admin (db, réseau ou système) est souvent très conservateur
et il a souvent raison. Cependant, si vous ne discutez pas des
pré-requis avec votre équipe d’exploitation, vous n’allez pas vous en
sortir.

++

yk

Le 07/08/07, Laurent[email protected] a écrit :

[laurent]

Oui tu as bien analysé la situation

Initialement on avait bien 2 instances oracle :
une en iso pour l’appli néhandertalienne
une autre, distante (sur un autre serveur), en UTF 8 pour notre appli
RoR.

Notre application avait besoin d’utiliser des tables du datamodel
néhandertalien, et donc évidemment completement hors conventions RoR :
Pour cela, on a du faire des vues (aux conventions ror sur les pk et
fk) a travers des database links, entre notre instance ‘ror’ et les
datamodels de la base de référence.
Alors pourquoi avoir tout réunifié? c’est une décision qui vient de
plus haut, et comme souvent, y a pas a discuter.
Réunifier surtout pour ne pas avoir 2 instances a gérer et éviter de
passer par des database links (et y gagner en perfs).

Seulement voila, désormais on est un peu dans le caca je dirais.

Pour la solution 2, à savoir inclure dans notre code (controleurs,
vues, rjs) des conversions de données , ca va etre couteux en terme
de temps vu que l’appli est assez grosse . On devra passer partout
dans le code, et ajouter ces appels iconv.

La solution 1 de faire la conversion sur un post filtre serait
l’ideale :

[quelques minutes se passent…]

On vient de la tester …
Pour cela , ajouter dans application.rb >>

after_filter :convert_response
def convert_response
@response.body =
Iconv.new(“UTF-8”,“iso-8859-1”).iconv(@response.body)
end

Cela résoud nos problèmes pour toutes les données en ISO provenant de
la base.
Pour l’instant, tout notre code source de l’app. RoR est tjs en ISO
On va continuer de tout tester.

Probleme donc partiellement résolu.

Laurent