"Langue du clavier" de l'internaute

[Selection A]

Bonsoir,

Y a t'il un moyen (via js par exemple) de récupérer la langue du clavier de l'internaute (et non la langue du navigateur) ?

Par exemple sur windows, avoir le LCID (1036/040C pour le français) ou le jeu de caractères (1252 pour le français)...

Merci d'avance

 

[jcaron]

Pas que je sache, à moins de s'aventurer dans un contrôle ActiveX ou peut-être une applet Java (Java, hein, pas Javascript).

Mais au niveau du navigateur tu peux avoir la variation de la langue (par exemple fr-FR, fr-CA, etc.), si ça peut t'être utile.

C'est quoi le but ultime?

Jacques.

 

[Selection A]

En fait je me posais une question générale sur l'encodage en imaginant l'impact de la "langue du clavier" sur un formulaire online ...

Si la balise meta de la page contentant le formulaire est :

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

Si l'internaute saisie par exemple un caractère cyrillique et valide le formulaire alors le caractère cyrillique sera transcodé en son code décimal &#xxx; issu de unicode

 

[jeanluc]

récupérer la langue du clavier de l'internaute

Ce serait plutôt la nationalité du clavier. Il y a des claviers belges qui sont différents des claviers français, mais qui sont les mêmes pour les belges francophones et flamands. Il y a aussi des claviers suisses, etc.

Que je sache, le clavier n'a pas d'importance; c'est l'OS du PC qui fait l'encodage en conséquence.

Jean-Luc

 

[jeanluc]

récupérer la langue du clavier de l'internaute

Ce serait plutôt la nationalité du clavier. Il y a des claviers belges qui sont différents des claviers français, mais qui sont les mêmes pour les belges francophones et flamands. Il y a aussi des claviers suisses, etc. Voir Disposition des touches des claviers informatiques.

Que je sache, le clavier n'a pas d'importance; c'est l'OS du PC qui fait l'encodage en conséquence.

Jean-Luc

 

[jcaron]

En fait je me posais une question générale sur l'encodage en imaginant l'impact de la "langue du clavier" sur un formulaire online ...

Si la balise meta de la page contentant le formulaire est :

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

Si l'internaute saisie par exemple un caractère cyrillique et valide le formulaire alors le caractère cyrillique sera transcodé en son code décimal &#xxx; issu de unicode

Je n'ai jamais vérifié, mais normalement (d'après la spec HTML), non, un navigateur ne doit pas accepter des caractères qui ne sont pas encodables dans le charset du formulaire (défini par l'attribut accept-charset, ou par défaut, par le charset de la page). Les caractères non-ASCII sont encodés sous forme %xx en application/x-www-form-urlencoded et en fonction du Content-Transfer-Encoding en multipart/form-data. L'encodage en &#xxx; n'est normalement pas autorisé.

La bonne solution c'est vraiment de tout passer en UTF-8, comme ça la question ne se posera même pas.

Jacques.

 

[Selection A]

Que je sache, le clavier n'a pas d'importance; c'est l'OS du PC qui fait l'encodage en conséquence.

oui et non à mon avis. par exemple si je suis sur un windows français (LCID = 1036/040C) :
avec un clavier français je vais "écrire" en windows-1252
avec un clavier russe (paramètrable via le panneau de configuration de windows) je vais écrire en unicode...

 

[Selection A]

Je n'ai jamais vérifié, mais normalement (d'après la spec HTML), non, un navigateur ne doit pas accepter des caractères qui ne sont pas encodables dans le charset du formulaire (défini par l'attribut accept-charset, ou par défaut, par le charset de la page

j'ai fait un test avec firefox et c'est autorisé. comme je le disais dans mo message précédent un caractère saisi qui ne correspond pas au charset du formulaire (ou de la page) sera transcodé en son code décimal &#xxx; issu de unicode

 

[Selection A]

Les caractères non-ASCII sont encodés sous forme %xx en application/x-www-form-urlencoded

il me semble que cela est vrai que si la methode du formulaire est GET

 

[jcaron]

oui et non à mon avis. par exemple si je suis sur un windows français (LCID = 1036/040C) :
avec un clavier français je vais "écrire" en windows-1252
avec un clavier russe (paramètrable via le panneau de configuration de windows) je vais écrire en unicode...

Euh non. Tu vas essentiellement écrire des caractères qui rentrent dans un ou plusieurs charsets. En français tu peux aussi bien faire du windows-1252, iso-8859-1, iso-8859-15, cp850 que de l'utf-8 ou de l'utf-16 par exemple. Mais rien ne t'empêche de copier-coller du cyrillique, du chinois, du japonais, par exemple (qui ont tous une version Unicode et des versions dans des charsets "locaux" adaptés). En pratique de toutes façons tous les browsers modernes doivent travailler en Unicode en interne, et font ensuite la conversion dans le charset adapté au moment du submit.

Je n'ai jamais vérifié, mais normalement (d'après la spec HTML), non, un navigateur ne doit pas accepter des caractères qui ne sont pas encodables dans le charset du formulaire (défini par l'attribut accept-charset, ou par défaut, par le charset de la page

j'ai fait un test avec firefox et c'est autorisé. comme je le disais dans mo message précédent un caractère saisi qui ne correspond pas au charset du formulaire (ou de la page) sera transcodé en son code décimal &#xxx; issu de unicode

Ca me semble non-standard et ça doit "casser" pas mal de choses, en particulier parce qu'il devient impossible de faire la différence entre moi qui tape &#xx; (littéralement) dans un champ et une entité, mais effectivement, Opera et IE le font aussi. La spec HTML 4 dit que le browser devrait t'empêcher de taper ces caractères s'il ne peut pas les encoder dans le charset utilisé, mais bon, c'est probablement un moindre mal. La spec HTML 5 prévoit effectivement de faire ça, mais uniquement en application/x-www-form-urlencoded.

Ceci dit, tout ça ne change rien au fait que le clavier utilisé n'est pas pertinent. Les caractères qui ne sont pas encodés sous forme d'entités sont dans le charset indiqué dans la page qui contient le formulaire (ou l'attribut encharset du formulaire, s'il est présent), et le reste ce sont des entités HTML/XML avec des codepoints Unicode, et tout ça quel que soit le clavier (qui peut par ailleurs changer en cours de route).

Les caractères non-ASCII sont encodés sous forme %xx en application/x-www-form-urlencoded

il me semble que cela est vrai que si la methode du formulaire est GET

Non, c'est vrai si l'enctype est application/x-www-form-urlencoded, que ce soit en GET ou en POST, c'est inhérent à cet encodage.

Conclusion de tout ça, si tu veux être sûr de ne pas avoir de problème, la seule solution c'est de tout passer en UTF-8.

Jacques.

 

[Selection A]

merci pour ces réponses ....

je m'en vais digérer tout ça :wink: