Est-ce que Seamonkey est devenu fou en abandonnant la détection du
jeu de caractère passé dans une méta et en ayant du UTF par défaut ?
Alors que mon site affichait toujours le bon jeu de caractères, voilà
qu'il est devenu illisible avec Seamonkey qui détecte du UTF8 au lieu
de 8859-1 ou WIndows 1252.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en"><head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=iso-8859-1">
J'utilise Gecko/20110420 SeaMonkey/2.0.14 et Firefox 4.0.1.
J'ai 90000 pages à modifier si je dois changer mes en-têtes et je
n'ai plus accès à mon générateur de pages (il roulait sous Windows
98 en DOS, ce que Windows 7 familial n'autorise pas...).
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
Bonjour,
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.
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
Le 16/07/2011 17:56, Olivier Miakinen 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...
Le 16/07/2011 17:56, Olivier Miakinen 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...
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...
Olivier Miakinen
Bonjour,
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.
Bonjour,
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.
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
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 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.
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.
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.
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...
On 16/07/2011 17:56, Olivier Miakinen wrote:
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...
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
On 18/07/2011 11:19, Olivier Miakinen wrote:
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 !
On 18/07/2011 11:19, Olivier Miakinen wrote:
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.
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 18/07/11 11:19, Olivier Miakinen a écrit :
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) -- Stéphane Moriaux avec/with iMac-intel
Le 18/07/11 11:19, Olivier Miakinen a écrit :
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)
--
Stéphane Moriaux avec/with iMac-intel
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) -- Stéphane Moriaux avec/with iMac-intel
Pierre Goiffon
On 18/07/2011 18:24, SAM wrote:
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.
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 !!)
On 18/07/2011 18:24, SAM wrote:
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.
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 !!)
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.
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 18/07/2011 18:24, SAM a écrit :
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 ?)
À 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).
Le 18/07/2011 18:24, SAM a écrit :
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 ?)
À 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).
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 ?)
À 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).
