Au sein d'un projet devant intégrer les "contraintes" de l'accessibilité,
nous avons réussi à produire - après une dépense d'énergie considérable de
ma part pour convaincre chaque intervenant du projet - une interface en HTML
4.01 Strict (sens, syntaxe et grammaire). :))
Un seul souci et pas des moindres... Au sein de l'éditeur de contenu intégré
au backoffice l'utilisation des "copier/coller" - est pour le moment -
autorisé... Donc les rédacteurs peuvent intégrer leurs contenus à partir
d'application comme MSWord... y compris les caractères appartenant à
l'encodage windows-1250...
Alors qu'en "Front" nous avons spécifié "iso-8859-1"... Pour faire simple,
cela me ferrais mal au coeur de spécifier un autre encodage (et surtout
windows-1250) :((
Donc mes questions sont :
1 - Connaissez vous une bibliothèque permettant la conversion d'un encodage
à l'autre ??
D'un point de vue "technique" l'application BackOffice est totalement
intégrée à l'environnement Windows :
- coté serveur : ASP3, SQLServer 200,...
- coté client : MSIE 5.XX pour Windows et supérieur.
2 - Si pas de conversion possible.
Et vue qu'il me semble difficile - d'un point de vue ergonomie - de
supprimer cette fonctionnalité, quelle est l'ampleur de l'implémentation du
"windows-1250" au sein des clients Web de tout poils??
En gros, mon comportement vis à vis de cette modification est-il justifié ?
Cela me chagrine au plus haut point et j'ais l'impression que nous allons
perdre d'une part en qualité et d'autre part dans la mise en place des
principes pour lesquelles je me bat chaque jour au sein de mon entreprise...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pierre Goiffon
[Avec ce crosspost de la mort, suivi positionné sur fr.comp.infosystemes.www.auteurs] (hbigal, lorsque l'on envoie à plusieurs groupes, il vaut mieux rediriger vers un seul de ces groupe, et l'indiquer dans son message)
Dans le message:bl0qf7$s6b$, hbigal a écrit:
Un seul souci et pas des moindres... Au sein de l'éditeur de contenu intégré au backoffice l'utilisation des "copier/coller" - est pour le moment - autorisé... Donc les rédacteurs peuvent intégrer leurs contenus à partir d'application comme MSWord... y compris les caractères appartenant à l'encodage windows-1250... Alors qu'en "Front" nous avons spécifié "iso-8859-1"...
C'est une chouette question que vous posez là, le prb se pose sur la quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient le bon encodage (META et entête HTTP) faisaient eux même la conversion avant de renvoyer leur contenu. Jamais réussi non plus à trouver confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
[Avec ce crosspost de la mort, suivi positionné sur
fr.comp.infosystemes.www.auteurs]
(hbigal, lorsque l'on envoie à plusieurs groupes, il vaut mieux
rediriger vers un seul de ces groupe, et l'indiquer dans son message)
Dans le message:bl0qf7$s6b$1@d03.completel.fr,
hbigal <XANTISPXbigrenouille@club-internet.fr> a écrit:
Un seul souci et pas des moindres... Au sein de l'éditeur de contenu
intégré au backoffice l'utilisation des "copier/coller" - est pour le
moment - autorisé... Donc les rédacteurs peuvent intégrer leurs
contenus à partir d'application comme MSWord... y compris les
caractères appartenant à l'encodage windows-1250...
Alors qu'en "Front" nous avons spécifié "iso-8859-1"...
C'est une chouette question que vous posez là, le prb se pose sur la
quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce
jour - si ce n'est une bibliothèque de conversion faite au fur et à
mesure (le mieux pour ça est de réaliser périodiquement une sortie XML
des derniers contenus saisis, de vérifier la validité et on trouve très
rapidement les caractères illégaux dans le charset)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient
le bon encodage (META et entête HTTP) faisaient eux même la conversion
avant de renvoyer leur contenu. Jamais réussi non plus à trouver
confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
--
_________________________________________________________
/
. Pierre GOIFFON .
. p g o i f f o n @ w e b c i t y . f r .
_________________________________________________________/
Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php
[Avec ce crosspost de la mort, suivi positionné sur fr.comp.infosystemes.www.auteurs] (hbigal, lorsque l'on envoie à plusieurs groupes, il vaut mieux rediriger vers un seul de ces groupe, et l'indiquer dans son message)
Dans le message:bl0qf7$s6b$, hbigal a écrit:
Un seul souci et pas des moindres... Au sein de l'éditeur de contenu intégré au backoffice l'utilisation des "copier/coller" - est pour le moment - autorisé... Donc les rédacteurs peuvent intégrer leurs contenus à partir d'application comme MSWord... y compris les caractères appartenant à l'encodage windows-1250... Alors qu'en "Front" nous avons spécifié "iso-8859-1"...
C'est une chouette question que vous posez là, le prb se pose sur la quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient le bon encodage (META et entête HTTP) faisaient eux même la conversion avant de renvoyer leur contenu. Jamais réussi non plus à trouver confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
s t e f
Pierre Goiffon wrote:
C'est une chouette question que vous posez là, le prb se pose sur la quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
Moi j'ai testé spip, et le champ saisi est reconverti proprement à la volée avant insertion dans la DB. Il faudrait éplucher le code (ce que je ne vais pas faire pour l'instant mais c'est en projet)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient le bon encodage (META et entête HTTP) faisaient eux même la conversion avant de renvoyer leur contenu. Jamais réussi non plus à trouver confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
... pas vraiment de réponse non plus... :-(
-- s t e f http://www.nota-bene.org/ (en rade pour quelques jours)
Pierre Goiffon wrote:
C'est une chouette question que vous posez là, le prb se pose sur la
quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce
jour - si ce n'est une bibliothèque de conversion faite au fur et à
mesure (le mieux pour ça est de réaliser périodiquement une sortie XML
des derniers contenus saisis, de vérifier la validité et on trouve très
rapidement les caractères illégaux dans le charset)
Moi j'ai testé spip, et le champ saisi est reconverti proprement à la
volée avant insertion dans la DB. Il faudrait éplucher le code (ce que
je ne vais pas faire pour l'instant mais c'est en projet)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient
le bon encodage (META et entête HTTP) faisaient eux même la conversion
avant de renvoyer leur contenu. Jamais réussi non plus à trouver
confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
... pas vraiment de réponse non plus... :-(
--
s t e f
http://www.nota-bene.org/ (en rade pour quelques jours)
C'est une chouette question que vous posez là, le prb se pose sur la quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
Moi j'ai testé spip, et le champ saisi est reconverti proprement à la volée avant insertion dans la DB. Il faudrait éplucher le code (ce que je ne vais pas faire pour l'instant mais c'est en projet)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient le bon encodage (META et entête HTTP) faisaient eux même la conversion avant de renvoyer leur contenu. Jamais réussi non plus à trouver confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
... pas vraiment de réponse non plus... :-(
-- s t e f http://www.nota-bene.org/ (en rade pour quelques jours)
Lea Gris
s t e f wrote:
Pierre Goiffon wrote:
C'est une chouette question que vous posez là, le prb se pose sur la quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
Moi j'ai testé spip, et le champ saisi est reconverti proprement à la volée avant insertion dans la DB. Il faudrait éplucher le code (ce que je ne vais pas faire pour l'instant mais c'est en projet)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient le bon encodage (META et entête HTTP) faisaient eux même la conversion avant de renvoyer leur contenu. Jamais réussi non plus à trouver confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
-- Léa Gris - http://www.noiraude.net/ () Campagne du ruban texte brut contre les courriels en HTML, / contre les pièces jointes dans un format propriétaire.
s t e f wrote:
Pierre Goiffon wrote:
C'est une chouette question que vous posez là, le prb se pose sur la
quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce
jour - si ce n'est une bibliothèque de conversion faite au fur et à
mesure (le mieux pour ça est de réaliser périodiquement une sortie XML
des derniers contenus saisis, de vérifier la validité et on trouve très
rapidement les caractères illégaux dans le charset)
Moi j'ai testé spip, et le champ saisi est reconverti proprement à la
volée avant insertion dans la DB. Il faudrait éplucher le code (ce que
je ne vais pas faire pour l'instant mais c'est en projet)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient
le bon encodage (META et entête HTTP) faisaient eux même la conversion
avant de renvoyer leur contenu. Jamais réussi non plus à trouver
confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
--
Léa Gris - http://www.noiraude.net/
() Campagne du ruban texte brut contre les courriels en HTML,
/ contre les pièces jointes dans un format propriétaire.
C'est une chouette question que vous posez là, le prb se pose sur la quasi totalité des CMS et ici ça a été assez épineux !
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
Moi j'ai testé spip, et le champ saisi est reconverti proprement à la volée avant insertion dans la DB. Il faudrait éplucher le code (ce que je ne vais pas faire pour l'instant mais c'est en projet)
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient le bon encodage (META et entête HTTP) faisaient eux même la conversion avant de renvoyer leur contenu. Jamais réussi non plus à trouver confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
-- Léa Gris - http://www.noiraude.net/ () Campagne du ruban texte brut contre les courriels en HTML, / contre les pièces jointes dans un format propriétaire.
C'est intéressant (pour ceux qui ne sont pas allé voir, c'est un moyen d'indiquer le charset accepté par le serveur) Mais : il y a un continent entre les recommandations W3C et leur réelle implémentation, et de plus c'est assez flou sur le comportement que doit adopter le navigateur. Qu'en est-il de la réalité, que donne l'usage de cet attribut à FORM en pratique ?
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Dans le message:bl1c3m$2ct1$1@biggoron.nerim.net,
Lea Gris <lea.gris@reply.invalid> a écrit:
C'est intéressant (pour ceux qui ne sont pas allé voir, c'est un moyen
d'indiquer le charset accepté par le serveur)
Mais : il y a un continent entre les recommandations W3C et leur réelle
implémentation, et de plus c'est assez flou sur le comportement que doit
adopter le navigateur. Qu'en est-il de la réalité, que donne l'usage de
cet attribut à FORM en pratique ?
--
_________________________________________________________
/
. Pierre GOIFFON .
. p g o i f f o n @ w e b c i t y . f r .
_________________________________________________________/
Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php
C'est intéressant (pour ceux qui ne sont pas allé voir, c'est un moyen d'indiquer le charset accepté par le serveur) Mais : il y a un continent entre les recommandations W3C et leur réelle implémentation, et de plus c'est assez flou sur le comportement que doit adopter le navigateur. Qu'en est-il de la réalité, que donne l'usage de cet attribut à FORM en pratique ?
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Fabrice Bonny
Pierre Goiffon disait:
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
Beaucoup plus simple en PHP qu'en ASP. :-(
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient le bon encodage (META et entête HTTP) faisaient eux même la conversion avant de renvoyer leur contenu. Jamais réussi non plus à trouver confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
Jamais vu non plus. Pas plus que le "accept" sur les input file. Encore une bonne idée du W3C jamais suivie. :-p
-- Fabrice Bonny - http://openweb.eu.org/
"I am working on open source software, not open binary; don't ask me to compile my code." Daniel Glazman
Pierre Goiffon disait:
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce
jour - si ce n'est une bibliothèque de conversion faite au fur et à
mesure (le mieux pour ça est de réaliser périodiquement une sortie XML
des derniers contenus saisis, de vérifier la validité et on trouve très
rapidement les caractères illégaux dans le charset)
Beaucoup plus simple en PHP qu'en ASP. :-(
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient
le bon encodage (META et entête HTTP) faisaient eux même la conversion
avant de renvoyer leur contenu. Jamais réussi non plus à trouver
confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
Jamais vu non plus. Pas plus que le "accept" sur les input file. Encore
une bonne idée du W3C jamais suivie. :-p
--
Fabrice Bonny - http://openweb.eu.org/
"I am working on open source software, not open binary; don't ask me to
compile my code." Daniel Glazman
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
Beaucoup plus simple en PHP qu'en ASP. :-(
J'avais cru cependant comprendre que les navigateurs, s'ils recevaient le bon encodage (META et entête HTTP) faisaient eux même la conversion avant de renvoyer leur contenu. Jamais réussi non plus à trouver confirmation de cela ni en documentation ni en pratique... Quelqu'un ?
Jamais vu non plus. Pas plus que le "accept" sur les input file. Encore une bonne idée du W3C jamais suivie. :-p
-- Fabrice Bonny - http://openweb.eu.org/
"I am working on open source software, not open binary; don't ask me to compile my code." Daniel Glazman
Pierre Goiffon
Dans le message:bl1io8$6dm64$, Fabrice Bonny a écrit:
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
Beaucoup plus simple en PHP qu'en ASP. :-(
Euh cad ? Il existe sans nulle doute des ActiveX qui font tous ces travaux de conversion très bien... Mhhh jamais pensé à chercher, il faudrait peut être regarder
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Dans le message:bl1io8$6dm64$1@ID-86835.news.uni-berlin.de,
Fabrice Bonny <fbonny@areste.net> a écrit:
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à
ce jour - si ce n'est une bibliothèque de conversion faite au fur et
à mesure (le mieux pour ça est de réaliser périodiquement une sortie
XML des derniers contenus saisis, de vérifier la validité et on
trouve très rapidement les caractères illégaux dans le charset)
Beaucoup plus simple en PHP qu'en ASP. :-(
Euh cad ?
Il existe sans nulle doute des ActiveX qui font tous ces travaux de
conversion très bien... Mhhh jamais pensé à chercher, il faudrait peut
être regarder
--
_________________________________________________________
/
. Pierre GOIFFON .
. p g o i f f o n @ w e b c i t y . f r .
_________________________________________________________/
Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php
Dans le message:bl1io8$6dm64$, Fabrice Bonny a écrit:
Je n'ai pour ma part pas trouvé de réponse vraiment satisfaisante à ce jour - si ce n'est une bibliothèque de conversion faite au fur et à mesure (le mieux pour ça est de réaliser périodiquement une sortie XML des derniers contenus saisis, de vérifier la validité et on trouve très rapidement les caractères illégaux dans le charset)
Beaucoup plus simple en PHP qu'en ASP. :-(
Euh cad ? Il existe sans nulle doute des ActiveX qui font tous ces travaux de conversion très bien... Mhhh jamais pensé à chercher, il faudrait peut être regarder
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Après cela le navigateur tien compte ou nom des encodages spécifiés selon ses capacités et celles de l'interface utilisateur.
OK pour la théorie, qu'en est-il de la pratique ? Avez vous un retour d'expérience sur le sujet ?
Bah on va testier tiens ;)
Laissez moi qqminutes que je pauvine un petit formulaire avec les variables qui vont bien
-- Léa Gris - http://www.noiraude.net/ () Campagne du ruban texte brut contre les courriels en HTML, / contre les pièces jointes dans un format propriétaire.
Pierre Goiffon wrote:
Dans le message:bl1dkk$2duq$1@biggoron.nerim.net,
Lea Gris <lea.gris@reply.invalid> a écrit:
Après cela le navigateur tien compte ou nom des encodages spécifiés
selon ses capacités et celles de l'interface utilisateur.
OK pour la théorie, qu'en est-il de la pratique ? Avez vous un retour
d'expérience sur le sujet ?
Bah on va testier tiens ;)
Laissez moi qqminutes que je pauvine un petit formulaire avec les variables
qui vont bien
--
Léa Gris - http://www.noiraude.net/
() Campagne du ruban texte brut contre les courriels en HTML,
/ contre les pièces jointes dans un format propriétaire.
Après cela le navigateur tien compte ou nom des encodages spécifiés selon ses capacités et celles de l'interface utilisateur.
OK pour la théorie, qu'en est-il de la pratique ? Avez vous un retour d'expérience sur le sujet ?
Bah on va testier tiens ;)
Laissez moi qqminutes que je pauvine un petit formulaire avec les variables qui vont bien
-- Léa Gris - http://www.noiraude.net/ () Campagne du ruban texte brut contre les courriels en HTML, / contre les pièces jointes dans un format propriétaire.
