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 :
>
>
>
> 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és
> provenant 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
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse [EMAIL PROTECTED]
-~----------~----~----~----~------~----~------~--~---
