Re: Encodage automatique
Denis Beauregard
Le Mon, 11 Jul 2011 17:08:26 +0200, Olivier Miakinen
<om+...@miakinen.net> écrivait dans
fr.comp.infosystemes.www.navigateurs:
>> Dans le 1er cas, c'est une décision de l'hébergeur
>
>Mauvais hébergeur, changer d'hébergeur. ©
Ce que je ferai peut-être dans les prochains mois (mon contrat de
4 ans expire bientôt).
>Si ton hébergeur ne met pas à ta disposition un moyen de choisir
>les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
>mauvais hébergeur et tu devrais en changer le plus tôt possible.
>
>D'autant plus qu'avec Apache, même si tu n'as pas accès au
>httpd.conf, il est très facile de contrôler ce que tu veux
>au moyens des .htaccess répertoire par répertoire.
M'enfin, pourquoi personne ne suggère comme faire un .htaccess
qui résoudrait ce problème ? J'ai beaucoup de dossiers dans mon
site et j'ai pu corriger le problème pour un sous-ensemble bien
identifié. Mais il y a peut-être d'autres dossiers où je devrais
ajouter un .htaccess pour m'assurer que tout est bien lu (même si
en théorie, tout est édité avec Seamonkey qui transforme les
lettres accentuées en entités).
Denis
P.S. Je sais que la solution est donnée sur une page comme
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
mais je suis surpris que personne n'a donné par réflexe cette
solution.
Olivier Miakinen
> suivi au forum des auteurs
Bonne idée.
> [quels entêtes HTTP envoyer avec un fichier donné pour préciser
> le type MIME, charset compris]
>
>>> Dans le 1er cas, c'est une décision de l'hébergeur
>>
>>Mauvais hébergeur, changer d'hébergeur. ©
>
> Ce que je ferai peut-être dans les prochains mois (mon contrat de
> 4 ans expire bientôt).
Par curiosité, quel hébergeur as-tu ? Tous ceux que j'ai utilisés
jusqu'à présent (Free, Teaser et GalacSys) permettaient de modifier
le .htaccess, et il n'y a guère que chez Wanadoo que j'ai entendu
dire que c'était impossible. Or, même dans ce dernier cas, je pense
qu'il y a moyen de dire si on envoie un fichier audio, une image
ou un document HTML -- au fait, comment font ceux qui envoient du
XHTML ?
>>Si ton hébergeur ne met pas à ta disposition un moyen de choisir
>>les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
>>mauvais hébergeur et tu devrais en changer le plus tôt possible.
>>
>>D'autant plus qu'avec Apache, même si tu n'as pas accès au
>>httpd.conf, il est très facile de contrôler ce que tu veux
>>au moyens des .htaccess répertoire par répertoire.
>
> M'enfin, pourquoi personne ne suggère comme faire un .htaccess
> qui résoudrait ce problème ?
Je vois plusieurs raisons à cela :
- tu traînes tes guêtres depuis suffisamment longtemps sur les
groupes php et infosystemes.www pour qu'on ait pensé que tu
le savais déjà ;
- la config par .htaccess est plutôt en charte sur fciw.serveurs
ou à la limite fciw.auteurs que fciw.navigateurs ;
- et bien sûr, si tes pages sont en PHP, un header() est une
solution tout aussi simple, voire plus.
> J'ai beaucoup de dossiers dans mon
> site et j'ai pu corriger le problème pour un sous-ensemble bien
> identifié. Mais il y a peut-être d'autres dossiers où je devrais
> ajouter un .htaccess pour m'assurer que tout est bien lu (même si
> en théorie, tout est édité avec Seamonkey qui transforme les
> lettres accentuées en entités).
Pourquoi ne pas mettre le .htaccess à la racine de ton site, si
tu n'as pas de mélange entre UTF-8 et Latin1 ? D'autant plus qu'il
suffit d'un autre .htaccess dans un sous-sous-sous-répertoire qui
contiendrait exceptionnellement des documents avec un autre jeu de
caractères.
> P.S. Je sais que la solution est donnée sur une page comme
> http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
> mais je suis surpris que personne n'a donné par réflexe cette
> solution.
Cf. supra.
Denis Beauregard
<om+...@miakinen.net> écrivait dans fr.comp.infosystemes.www.auteurs:
>Le 11/07/2011 17:35, Denis Beauregard a écrit :
>> suivi au forum des auteurs
>
>Bonne idée.
>
>> [quels entêtes HTTP envoyer avec un fichier donné pour préciser
>> le type MIME, charset compris]
>>
>>>> Dans le 1er cas, c'est une décision de l'hébergeur
>>>
>>>Mauvais hébergeur, changer d'hébergeur. ©
>>
>> Ce que je ferai peut-être dans les prochains mois (mon contrat de
>> 4 ans expire bientôt).
>
>Par curiosité, quel hébergeur as-tu ? Tous ceux que j'ai utilisés
>jusqu'à présent (Free, Teaser et GalacSys) permettaient de modifier
>le .htaccess, et il n'y a guère que chez Wanadoo que j'ai entendu
>dire que c'était impossible. Or, même dans ce dernier cas, je pense
>qu'il y a moyen de dire si on envoie un fichier audio, une image
>ou un document HTML -- au fait, comment font ceux qui envoient du
>XHTML ?
Je vais faire des .htaccess (je me suis aperçu que mon index n'a pas
d'include initial comme les autres pages) et donc qu'il y a là le
problème d'accents, aussi présent dans d'autres pages que j'ai
modifiées directement sans Seamonkey.
Mon hébergeur est Flexi, en Australie.
>>>Si ton hébergeur ne met pas à ta disposition un moyen de choisir
>>>les entêtes HTTP à envoyer avec tel ou tel document, c'est un très
>>>mauvais hébergeur et tu devrais en changer le plus tôt possible.
>>>
>>>D'autant plus qu'avec Apache, même si tu n'as pas accès au
>>>httpd.conf, il est très facile de contrôler ce que tu veux
>>>au moyens des .htaccess répertoire par répertoire.
>>
>> M'enfin, pourquoi personne ne suggère comme faire un .htaccess
>> qui résoudrait ce problème ?
>
>Je vois plusieurs raisons à cela :
>- tu traînes tes guêtres depuis suffisamment longtemps sur les
> groupes php et infosystemes.www pour qu'on ait pensé que tu
> le savais déjà ;
Je n'aurais pas posé la question si j'avais su cela...
>- la config par .htaccess est plutôt en charte sur fciw.serveurs
> ou à la limite fciw.auteurs que fciw.navigateurs ;
Initialement, j'ai pensé avoir un problème de navigateur. C'est
plus tard que j'ai vu que c'était le serveur en soit.
>- et bien sûr, si tes pages sont en PHP, un header() est une
> solution tout aussi simple, voire plus.
Mais je n'ai plus mon bon vieil éditeur DOS multi-fichiers. Je sais
que je devrais me mettre à emacs ou vim (mon 1er choix étant emacs)
mais pour le moment, je devrais éditer les fichiers un à la fois...
>> J'ai beaucoup de dossiers dans mon
>> site et j'ai pu corriger le problème pour un sous-ensemble bien
>> identifié. Mais il y a peut-être d'autres dossiers où je devrais
>> ajouter un .htaccess pour m'assurer que tout est bien lu (même si
>> en théorie, tout est édité avec Seamonkey qui transforme les
>> lettres accentuées en entités).
>
>Pourquoi ne pas mettre le .htaccess à la racine de ton site, si
>tu n'as pas de mélange entre UTF-8 et Latin1 ? D'autant plus qu'il
>suffit d'un autre .htaccess dans un sous-sous-sous-répertoire qui
>contiendrait exceptionnellement des documents avec un autre jeu de
>caractères.
Tout est en latin-1 ou windows 1252.
>> P.S. Je sais que la solution est donnée sur une page comme
>> http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
>> mais je suis surpris que personne n'a donné par réflexe cette
>> solution.
>
>Cf. supra.
Je devrais pouvoir faire la correction pour l'ensemble du site
cette semaine.
Denis
SAM
>
> le fichier inclus dans
> tous ces fichiers appelle l'anti-aspirateur de site
je ne sais pas trop ce qu'est un anti-aspirateur de site
cependant ... ne vaudrait-il pas mieux l'avoir dans le .htaccess ?
ne surchargeant dont pas ni les pages ni les accès serveur
te libérant de ce soucis lors de la rédaction de nouvelles pages
<http://www.tutoriaux-excalibur.com/anti-aspirateur.htm>
--
Stéphane Moriaux avec/with iMac-intel
Jean-Francois Ortolo
>
> je ne sais pas trop ce qu'est un anti-aspirateur de site
>
> cependant ... ne vaudrait-il pas mieux l'avoir dans le .htaccess ?
>
> ne surchargeant dont pas ni les pages ni les accès serveur
> te libérant de ce soucis lors de la rédaction de nouvelles pages
>
> <http://www.tutoriaux-excalibur.com/anti-aspirateur.htm>
>
Bonjour Monsieur
Et... Qu'est-ce que donne un anti-aspirateur de site, avec les
visites des bots des moteurs de recherche, qui sont répétitives ?
Celà ne gêne-t-il pas l'indexation des sites ?
Merci beaucoup de votre réponse.
Bien à vous.
Amicalement.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques,
Pronostics et Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr
Denis Beauregard
<ortolo.jeanfr...@free.fr.invalid> �crivait dans
fr.comp.infosystemes.www.auteurs:
>Le 12/07/2011 11:03, SAM a �crit :
>>
>> je ne sais pas trop ce qu'est un anti-aspirateur de site
Un dispositif qui emp�che un visiteur de recopier un gros site. Dans
mon cas, c'est 3 sections de 30 000 pages.
>> cependant ... ne vaudrait-il pas mieux l'avoir dans le .htaccess ?
Impossible � param�triser. De plus, certains aspirateurs ne sont
pas identifi�s par le USER-AGENT.
>> ne surchargeant dont pas ni les pages ni les acc�s serveur
>> te lib�rant de ce soucis lors de la r�daction de nouvelles pages
>>
>> <http://www.tutoriaux-excalibur.com/anti-aspirateur.htm>
>>
> Et... Qu'est-ce que donne un anti-aspirateur de site, avec les
>visites des bots des moteurs de recherche, qui sont r�p�titives ?
Il suffit d'identifier les bots des moteurs de recherche et de les
laisser passer.
> Cel� ne g�ne-t-il pas l'indexation des sites ?
Dans mon cas, ce qui nuit le plus, ce sont ceux qui copient des pages
de mon site et qui donnent l'impression que mon site a des pages en
double. En fait, j'utilise les alertes de Google et pratiquement tout
ce que je re�ois, ce sont des alertes de sites qui recopient tout le
monde (avec des recherches factices depuis l'API de Yahoo par
exemple) et non des sites qui parleraient du mien.
Denis
Pierre Goiffon
> Tout est en latin-1 ou windows 1252.
Alors tout peut être servit en windows-1252, car ce codage est une
extensions de iso latin-1.
Cf l'excellent outil de Olivier : http://www.miakinen.net/vrac/charsets
Jean-Marc Desperrier
> pourquoi personne ne suggère comme faire un .htaccess
> qui résoudrait ce problème ?
Voici un site qui explique en détail les diverses techniques :
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
La version de base est :
AddCharset UTF-8 .html
Il faut que l'hébergeur autorise au moins la surcharge des paramètres de
type FileInfo dans AllowOverride :
http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride
Denis Beauregard
<denis.b-at-franc...@nospam.com.invalid> �crivait dans
fr.comp.infosystemes.www.auteurs:
>P.S. Je sais que la solution est donn�e sur une page comme
>http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
>mais je suis surpris que personne n'a donn� par r�flexe cette
>solution.
Correction faite. J'ai choisi cette solution dans le .htaccess :
<FilesMatch "\.(htm|html|php)$">
ForceType 'text/html; charset=Windows-1252'
</FilesMatch>
J'ai choisi ce jeu au lieu du ISO parce que sur certaines pages,
j'ai remarqu� que j'avais des apostrophes fran�aises qui sortent
bien avec cet encodage et pas avec ISO. Je ne sais pas si cela
sortira bien sur Mac et Linux.
Une page comme celle contient les accents
http://www.francogene.com/genealogie--quebec/999/index.php
et j'�limine les fameuses apostrophones fran�aises quand je
g�n�re ces pages.
Mais je sais que j'ai d'autres pages avec ces apostrophes et
je ne sais pas comment trouver des pages sur mon site avec ce
caract�re. L'outil de recherche de Windows 7 dit que j'en ai dans tous
les fichiers, ce qui est faux...
Denis
Lea Gris
<troll type="hairy">
Comme une cellule de prison est l'extension d'une chambre d'hôtel.
</troll>
S'il faut à tout prix rester en codage 8bits, iso-8859-15 est une
meilleure extension standard.
Maintenant il n'y a aucune raison de ne pas passer à utf-8 du moment que
les en-têtes HTTP et l'encodage du texte est bien fait et bien traité
par l'application serveur.
--
Lea Gris
Denis Beauregard
écrivait dans fr.comp.infosystemes.www.auteurs:
>Le 12/07/2011 15:10, Pierre Goiffon a écrit :
>> On 12/07/2011 01:56, Denis Beauregard wrote:
>>> Tout est en latin-1 ou windows 1252.
>>
>> Alors tout peut être servit en windows-1252, car ce codage est une
>> extensions de iso latin-1.
>> Cf l'excellent outil de Olivier : http://www.miakinen.net/vrac/charsets
>
><troll type="hairy">
>Comme une cellule de prison est l'extension d'une chambre d'hôtel.
></troll>
>
>S'il faut à tout prix rester en codage 8bits, iso-8859-15 est une
>meilleure extension standard.
Mais il y a au moins un cas dans lequel il faut conserver 1252 :
si on a beaucoup de pages avec les caractères exclusifs à 1252 et
qu'on ne peut pas les détecter. Je sais que c'est le cas de mon site.
Je ne sais pas où sont ces pages mais j'ai identifié la suivante
http://www.francogene.com/rech-fr/dep-fr.php
avec ce texte
Départements disparus ou renommés
Les pays indiqués sont ceux d?aujourd?hui. À l?époque du changement,
la carte de l?Europe était très différente de celle d?aujourd?hui et
plusieurs pays étaient morcelés. Les changements récents se font en
deux temps: un vote et un changement réel des frontières ou du nom.
>Maintenant il n'y a aucune raison de ne pas passer à utf-8 du moment que
>les en-têtes HTTP et l'encodage du texte est bien fait et bien traité
>par l'application serveur.
Si on fait tout à la main ????
Denis
SAM
> Le Wed, 13 Jul 2011 18:06:44 +0200, Lea Gris<l...@nomail.invalid>
> écrivait dans fr.comp.infosystemes.www.auteurs:
>
> si on a beaucoup de pages avec les caractères exclusifs à 1252 et
> qu'on ne peut pas les détecter. Je sais que c'est le cas de mon site.
> Je ne sais pas où sont ces pages mais j'ai identifié la suivante
>
> http://www.francogene.com/rech-fr/dep-fr.php
>
> avec ce texte
>
> Départements disparus ou renommés
> Les pays indiqués sont ceux d?aujourd?hui. À l?époque du changement,
> la carte de l?Europe était très différente de celle d?aujourd?hui et
Non, non, chez moi (sur Mac en France et avec Firefox) les apostrophes
"français" sont bien affichés.
Ha! Ha! je vois que l'en-tête :
Content-Type: text/html; charset=windows-1252
semble bien passer.
et dans le source, là maintenant sans doute revu par Fx au passage, ce
n'est pas impossible que ce soit des ' penchés, des ´ ? (apostrophes ?
accents ? je ne saurais dire)
Ça reste OK en iso-8859-1 et cafouille en iso-8859-15 et aussi en utf-8
>> Maintenant il n'y a aucune raison de ne pas passer à utf-8 du moment que
>> les en-têtes HTTP et l'encodage du texte est bien fait et bien traité
>> par l'application serveur.
>
> Si on fait tout à la main ????
Je pense que Lea n'a pas bien saisi qu'il y avait déjà 215 000 pages
déjà écrites ;-)
Mébon ... Olivier Miakinen va certainement te trouver une petite
expression régulière associée à une routine php pour recomposer toutes
les pages déjà sur le serveur (sans avoir à les rapatrier puis les y
remettre) ;-)
Denis Beauregard
<denis.b-at-franc...@nospam.com.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:
>Le Mon, 11 Jul 2011 11:35:11 -0400, Denis Beauregard
><denis.b-at-franc...@nospam.com.invalid> écrivait dans
>fr.comp.infosystemes.www.auteurs:
>
>>P.S. Je sais que la solution est donnée sur une page comme
>>http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
>>mais je suis surpris que personne n'a donné par réflexe cette
>>solution.
>
>Correction faite. J'ai choisi cette solution dans le .htaccess :
>
>
><FilesMatch "\.(htm|html|php)$">
>ForceType 'text/html; charset=Windows-1252'
></FilesMatch>
Effet secondaire : mon code PHP ne marche plus !!! Si j'enlève ces
lignes du .htaccess, le PHP fonctionne de nouveau...
Il me reste à vérifier les autres solutions.
Denis
Olivier Miakinen
>
>
> extensions de iso latin-1.
Je ne recommande pas l'utilisation de windows-1252 dans l'absolu, mais
quitte à envoyer des caractères de ce jeu je suis d'accord qu'il vaut
mieux les annoncer correctement plutôt que de faire croire à de l'ISO.
> Cf l'excellent outil de Olivier : http://www.miakinen.net/vrac/charsets
Merci pour la pub !
Olivier Miakinen
>>
>>Correction faite. J'ai choisi cette solution dans le .htaccess :
>>
>><FilesMatch "\.(htm|html|php)$">
>>ForceType 'text/html; charset=Windows-1252'
>></FilesMatch>
>
> lignes du .htaccess, le PHP fonctionne de nouveau...
>
Je parie pour :
<FilesMatch "\.(htm|html|php)$">
AddDefaultCharset Windows-1252
</FilesMatch>
Pierre Goiffon
>>> Tout est en latin-1 ou windows 1252.
>>
>> Alors tout peut être servi en windows-1252, car ce codage est une
>> extensions de iso latin-1.
>
> Je ne recommande pas l'utilisation de windows-1252 dans l'absolu
Lea Gris donnait la même réponse et également sans l'argumenter, je suis
curieux de connaître les raisons qui vous poussent l'un et l'autre à
cette position ?
Pour le web, je ne crois pas qu'il y ait aujourd'hui grande différence.
J'ai mémoire d'avoir vu plusieurs signalement de soucis avec ISO Latin-9
sur Netscape 4 et IE5 mac ou 5 et 5.5 Windows, mais on peut considérer
qu'il s'agit d'une histoire ancienne.
Par contre, pour les outils, je ne connais que bien peu ne serait-ce que
d'éditeurs qui supportent réellement et correctement ISO Latin-9.
Windows-1252 me semble par contre très largement répandu et supporté, et
à ma connaissance également sur Mac et Linux.
Pierre Goiffon
>>> Maintenant il n'y a aucune raison de ne pas passer à utf-8 du moment que
>>> les en-têtes HTTP et l'encodage du texte est bien fait et bien traité
>>> par l'application serveur.
>>
>> Si on fait tout à la main ????
>
> Je pense que Lea n'a pas bien saisi qu'il y avait déjà 215 000 pages
> déjà écrites ;-)
>
> Mébon ... Olivier Miakinen va certainement te trouver une petite
> expression régulière associée à une routine php pour recomposer toutes
> les pages déjà sur le serveur (sans avoir à les rapatrier puis les y
> remettre) ;-)
Il y a des modules Apache (je me souvenais d'un dérivé de iConv, pas
retrouvé mais je suis tombé sur un mod_charset_lite), sinon l'habituel
recode lancé sur un shell distant... Ca reste dans les possibilités.
Mais il faudrait qu'il y ait un intérêt, Windows-1252 me parait très
bien convenir.
Pierre Goiffon
> Mais il y a au moins un cas dans lequel il faut conserver 1252 :
> si on a beaucoup de pages avec les caractères exclusifs à 1252 et
> qu'on ne peut pas les détecter. Je sais que c'est le cas de mon site.
> Je ne sais pas où sont ces pages mais j'ai identifié la suivante
>
> http://www.francogene.com/rech-fr/dep-fr.php
>
> avec ce texte
>
> Départements disparus ou renommés
> Les pays indiqués sont ceux d?aujourd?hui. À l?époque du changement,
> la carte de l?Europe était très différente de celle d?aujourd?hui et
> plusieurs pays étaient morcelés. Les changements récents se font en
> deux temps: un vote et un changement réel des frontières ou du nom.
En effet, cette apostrophe est U+2019 (merci Unired), qui en
Windows-1252 se code 0x92 (merci
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT),
et en ISO Latin-9... n'existe pas (merci
http://www.unicode.org/Public/MAPPINGS/ISO8859/8859-15.TXT).
Olivier Miakinen
Le 15/07/2011 11:50, Pierre Goiffon a écrit :
>>
>> Je ne recommande pas l'utilisation de windows-1252 dans l'absolu
>
> Lea Gris donnait la même réponse et également sans l'argumenter, je suis
> curieux de connaître les raisons qui vous poussent l'un et l'autre à
> cette position ?
Par hypercorrection et haine de Microsoft, ça te va comme réponse ? ;-)
En fait, il y a une raison objective qui est que Windows-1252 est une
norme non figée, qui pourrait encore évoluer sans changer de nom comme
elle l'a déjà fait le jour où Microsoft a ajouté le symbole de l'euro
à la position 128. Mais je suis d'accord qu'il n'y a que très peu de
chances que cela arrive un jour, et au contraire ça a toutes les chances
de se produire avec Unicode et donc UTF-8.
Donc la raison est plutôt une pétition de principe plutôt qu'une vraie
raison technique. Cela dit, cette raison me semble parfaitement fondée
et recevable. Elle n'est pas plus critiquable que la position des
partisans du libre pur et dur qui refusent d'installer Flash sur leur
Linux.
> Pour le web, je ne crois pas qu'il y ait aujourd'hui grande différence.
> J'ai mémoire d'avoir vu plusieurs signalement de soucis avec ISO Latin-9
> sur Netscape 4 et IE5 mac ou 5 et 5.5 Windows, mais on peut considérer
> qu'il s'agit d'une histoire ancienne.
> Par contre, pour les outils, je ne connais que bien peu ne serait-ce que
> d'éditeurs qui supportent réellement et correctement ISO Latin-9.
Note que là je suis d'un avis opposé à celui de Léa Gris : ISO Latin-9
n'est *pas* une bonne solution pour le web. Soit on utilise le charset
par défaut de sa machine parce qu'on ne sait pas faire autrement (donc
soit Latin1, soit Windows-1252, soit Macintosh c'est-à-dire MacRoman),
soit on sait faire autrement et on passe à UTF-8.
> Windows-1252 me semble par contre très largement répandu et supporté, et
> à ma connaissance également sur Mac et Linux.
Est-ce que quelqu'un a des infos concernant NetBSD et OpenBSD ? Je ne
m'inquiète pas trop pour FreeBSD.
Cordialement,
--
Olivier Miakinen
Vincent
> En fait, il y a une raison objective qui est que Windows-1252 est une
> chances que cela arrive un jour, et au contraire ï¿œa a toutes les chances
> de se produire avec Unicode et donc UTF-8.
Pourquoi y aurait-il une quelconque "chance" (risque...) pour que les
caractï¿œres unicode changent de code ?
Je croyais que c'ï¿œtait prï¿œcisï¿œment incompatible avec les principes mï¿œmes
d'unicode...
Olivier Miakinen
Le 17/07/2011 01:47, Vincent a écrit :
>
>> En fait, il y a une raison objective qui est que Windows-1252 est une
>> norme non figée, qui pourrait encore évoluer sans changer de nom
>> [...] il n'y a que très peu de
>> chances que cela arrive un jour, et au contraire ça a toutes les chances
>> de se produire avec Unicode et donc UTF-8.
>
> Pourquoi y aurait-il une quelconque "chance" (risque...) pour que les
> caractères unicode changent de code ?
> Je croyais que c'était précisément incompatible avec les principes mêmes
> d'unicode...
Tu as raison, il n'y a aucune chance que les caractères Unicode
*changent* de code, et d'ailleurs ce n'est pas ce que je disais.
Ce qui ne manquera pas d'arriver, c'est que de *nouveaux*
caractères soient introduits, sans que cela n'influe sur le
nom du charset (UTF-8). Et en fait c'est bien ce qui s'est
produit pour le jeu de caractères Windows-1252.
Il y a bien un exemple de jeu où au moins un caractère a *changé*,
et c'est MacRoman. Ce n'est pas Unicode ou UTF-8, et à priori je
ne crois pas que ça ait été le cas non plus de Windows-1252.
Olivier Miakinen
>
> Il y a bien un exemple de jeu où au moins un caractère a *changé*,
> et c'est MacRoman.
Je viens de vérifier, et c'est même pire que ce que je pensais :
alors que je croyais que le charset macintosh avait été enregistré
auprès de l'IANA avec le symbole de l'euro, je m'aperçois qu'il a
été enregistré en 1992 avec le symbole de monnaie indifférencié,
et que le changement vers l'euro a été fait en 1998 avec MacOS 8.5.
Sources :
http://www.iana.org/assignments/character-sets
http://www.faqs.org/rfcs/rfc1345.html
http://en.wikipedia.org/wiki/Mac_OS_Roman
http://en.wikipedia.org/wiki/Mac_OS_8
Pierre Goiffon
>>> Je ne recommande pas l'utilisation de windows-1252 dans l'absolu
>>
>> Lea Gris donnait la même réponse et également sans l'argumenter, je suis
>> curieux de connaître les raisons qui vous poussent l'un et l'autre à
>> cette position ?
>
> Par hypercorrection et haine de Microsoft, ça te va comme réponse ? ;-)
C'est ce qu'il me semblait :)
> En fait, il y a une raison objective qui est que Windows-1252 est une
> norme non figée, qui pourrait encore évoluer sans changer de nom comme
> elle l'a déjà fait le jour où Microsoft a ajouté le symbole de l'euro
> à la position 128. Mais je suis d'accord qu'il n'y a que très peu de
> chances que cela arrive un jour
N'est-ce pas :)
>> J'ai mémoire d'avoir vu plusieurs signalement de soucis avec ISO Latin-9
>> sur Netscape 4 et IE5 mac ou 5 et 5.5 Windows, mais on peut considérer
>> qu'il s'agit d'une histoire ancienne.
>> Par contre, pour les outils, je ne connais que bien peu ne serait-ce que
>> d'éditeurs qui supportent réellement et correctement ISO Latin-9.
>
> Note que là je suis d'un avis opposé à celui de Léa Gris : ISO Latin-9
> n'est *pas* une bonne solution pour le web. Soit on utilise le charset
> par défaut de sa machine parce qu'on ne sait pas faire autrement (donc
> soit Latin1, soit Windows-1252, soit Macintosh c'est-à-dire MacRoman),
> soit on sait faire autrement et on passe à UTF-8.
Sur des sites dynamiques on n'a malheureusement parfois pas trop le
choix de par les outils que l'on utilise, et UTF-8 n'est pas toujours
adoptable aussi facilement...
Et également, si l'on n'a pas besoin de la richesse de Unicode, rester
sur un charset 8 bits peut être une précaution utile : des tonnes de
parser Unicode sont encore très incorrectement développés, et conduisent
à des fuites de mémoire, des failles, des crash de serveur, ... (et ça
n'est pas une blague, j'ai rencontré le prb plusieurs fois au cours des
dernières années !)
Pour moi, pour des langues d'Europe de l'Ouest, Windows-1252 reste le
meilleur compromis pour des pages Web si l'on souhaite rester sur un
charset 8 bits.
ISO Latin-9 ne comprend d'ailleurs par tous les caractères présents dans
Windows-1252, et en particulier ceux issus de la correction automatique
de Office...
Pierre Goiffon
>> Il y a bien un exemple de jeu où au moins un caractère a *changé*,
>> et c'est MacRoman.
>
> Je viens de vérifier, et c'est même pire que ce que je pensais :
> alors que je croyais que le charset macintosh avait été enregistré
> auprès de l'IANA avec le symbole de l'euro, je m'aperçois qu'il a
> été enregistré en 1992 avec le symbole de monnaie indifférencié,
> et que le changement vers l'euro a été fait en 1998 avec MacOS 8.5.
Intéressant ! Merci de cette recherche Olivier !
SAM
> Le 17/07/2011 22:46, j'écrivais :
>>
>> Il y a bien un exemple de jeu où au moins un caractère a *changé*,
>> et c'est MacRoman.
>
> Je viens de vérifier, et c'est même pire que ce que je pensais :
> alors que je croyais que le charset macintosh avait été enregistré
> auprès de l'IANA
Le charset MacRoman est un charset "privé"
« the Apple Standard Roman character set »
(à ce titre, son créateur/propriétaire peut bien en faire ce qu'il veut,
non ?)
> avec le symbole de l'euro, je m'aperçois qu'il a
> été enregistré en 1992 avec le symbole de monnaie indifférencié,
> et que le changement vers l'euro a été fait en 1998 avec MacOS 8.5.
Au siècle dernier, dans le soft wisiwig de la marque de création HTML,
sous Windows pour obtenir le @ il fallait taper Alt+6+4 ... alors ...
l'euro ? ... mais mon pov' on en était encore aux html-entités ! !
(de mémoire : le soft passait tous les accentués en html-entités-alpha)
> Sources :
vu le bo...l dans les claviers Mac "français"(*) y avait quand même pas
à espérer qu'Apple fasse les choses simplement ;-)
(*)
clavier Canadien-Anglais : <http://cjoint.com/11ju/AGmodsm9FnV>
clavier Canadien-Français : <http://cjoint.com/?AGmod5Wbjfg>
claviers Belge, Suisse, Français ... je n'ai pas fait les captures.
Et sur les claviers chinois ... l'€ je ne sais où il est.
Sur le clavier Fr-fr Apple, l'€ s'obtient par Alt + $
même sur les vieux claviers où le gravage € est absent de la touche.
(bien sûr le $ n'y est pas à la même place que sur les claviers Windows
ou que Linux)
Pierre Goiffon
> vu le bo...l dans les claviers Mac "fran�ais"(*) y avait quand m�me pas
> � esp�rer qu'Apple fasse les choses simplement ;-)> clavier Canadien-Fran�ais : <http://cjoint.com/?AGmod5Wbjfg>
> claviers Belge, Suisse, Fran�ais ... je n'ai pas fait les captures.
Mais �a semble assez r�pandu ! J'ai un ami qui avait eu la mauvaise
surprise de d�couvrir un clavier tr�s bizarre sur le pc qu'il avait
achet�, c'�tait un clavier belge !
Plusieurs dispositions de clavier sont list�es chez IBM :
http://www-01.ibm.com/software/globalization/topics/keyboards/registry_index.html
Et MS �galement :
http://msdn.microsoft.com/fr-fr/goglobal/bb964651.aspx
A noter que sur Windows MS a fournit tr�s vite et gratuitement un outil
pour cr�er ses propres layout, et ils sont importables facilement !
http://msdn.microsoft.com/fr-fr/goglobal/bb964665.aspx
(et on ne peut que rappeler l'excellent travail de Denis Liegeois,
r�alis� sans cet outil ouille ouille ouille :
http://www.dicomoche.net/kbdfrac.htm)
Mais bon comme tu le souligne pas des exemples Apple a les siens propres
(car en effet d�j� le fr-fr, il faut s'y retrouver lorsque l'on vient du
pc !!)
Olivier Miakinen
>
> Le charset MacRoman est un charset "privé"
> « the Apple Standard Roman character set »
> (à ce titre, son créateur/propriétaire peut bien en faire ce qu'il veut,
> non ?)
Oui mais non. ©
À partir du moment où il a été rendu public dans le RFC 1345 et
enregistré par l'IANA pour être utilisé sur Internet, il n'est
plus privé (IANA = Internet assigned numbers authority). Tout
comme le jeu windows-1252.
Plus exactement, c'est le jeu "macintosh" qui n'est plus privé.
Un jeu qui a au moins deux différences avec le jeu MacRoman,
aux positions 0xDB (currency sign au lieu de l'euro) et 0xF0
(rien au lieu du logo Apple).
Denis Beauregard
<om+...@miakinen.net> écrivait dans fr.comp.infosystemes.www.auteurs:
>Le 15/07/2011 02:11, Denis Beauregard a écrit :
>>>
>>>Correction faite. J'ai choisi cette solution dans le .htaccess :
>>>
>>><FilesMatch "\.(htm|html|php)$">
>>>ForceType 'text/html; charset=Windows-1252'
>>></FilesMatch>
>>
>> Effet secondaire : mon code PHP ne marche plus !!! Si j'enlève ces
>> lignes du .htaccess, le PHP fonctionne de nouveau...
>>
>> Il me reste à vérifier les autres solutions.
>
>Je parie pour :
>
><FilesMatch "\.(htm|html|php)$">
>AddDefaultCharset Windows-1252
></FilesMatch>
Pari gagné ! Bravo !
En fait, j'ai enlevé qui me semble être le seul caractère 1252 hors
de Latin1 et j'ai utilisé latin1.
Denis