Salut à tous,
Je veux utiliser un soft qui supporte fr_FR ISO-8859-1, mais j'ai UTF-8. (le LANG et le LC_CTYPE)
Comment dois-je m'y prendre pour modifier ?

Par avance merci et salut à tous.
Pascal 🙂
si tu aime la ligne de commande fait un loadkeys
sinon va voir dans ton centre de controle
spirit wrote:si tu aime la ligne de commande fait un loadkeys
sinon va voir dans ton centre de controle
Te remercie.
...
Attention, une police de caracteres ca n'est pas une locale ave son encodage de caracteres. De meme que loadkeys charge une map clavier, et ne change en rien l'encodage des caracteres.

Je vous conseille le 'man 7 locale' a tous les deux, et a pascal_1212 de mieux decrire ses problemes au lieu d'essayer de mettre en oeuvre des solutions sans doute bancales.
Effectivement, loadkeys va charger un "keymap" , je ne pense pas que tu cherches à remplacer le "A" de ton clavier par un "Q" c'est un peu plus cérébral pour écrire ensuite.

une mise à jour des variables de localisation avant de lancer le soft fera l'affaire.


exemple :
export LANG=fr_FR.ISO-8859-1

il sera surement nécéssaire de modifier aussi quelques variables globales de type LC_xxxx
La modification de LC_ALL est rarement justifiée c'est un peu bourrin, mais fonctionne.
La modification de LC_ALL est rarement justifiée c'est un peu bourrin, mais fonctionne.
Cette variable ne sert que pour ecraser la locale courante pour des commandes ponctuelles, elle ne doit jamais etre definie dans une conf de shell, ou dans un environnement par defaut. Mais elle _doit_ etre definie dans d'autres situations comme dans un shell script ou tu commences a lancer en les pipants avec des grep..
Anvil wrote:Attention, une police de caracteres ca n'est pas une locale ave son encodage de caracteres. De meme que loadkeys charge une map clavier, et ne change en rien l'encodage des caracteres.

Je vous conseille le 'man 7 locale' a tous les deux, et a pascal_1212 de mieux decrire ses problemes au lieu d'essayer de mettre en oeuvre des solutions sans doute bancales.
Te remercie de me rendre attentif et de me donner un man,
En revanche, il est clair que je suis un bleu ! Donc, si je pose mal mes questions ou si elles manquent de qque chose, je te prie de me le faire savoir. Ainsi, je ne polue pas le forum.

Dans tous les cas merci à tous et à Fanf pour son exemple.
Je compléterais ce poste avec la méthode. Ainsi, si celà pourra profiter à d'autre user.
Pascal
...
Fanf wrote:export LANG=fr_FR.ISO-8859-1
export ne change la variable d'environnement que pour la session

essai plutot un setenv
C'était bien le but il me semble ?

Le changement n'est nécessaire que pour le lancement d'un soft particulier, il me parrait plus judicieux de le lancer à partir de la console qui aura redéfini la variable d'environnement.

Quitte à créer un petit lanceur de 3 lignes pour aller plus vite.

Ca évitera d'influencer sur les autres services.
Messieurs,
les raiponses me plaise 🙂
Je précise ma pencée. Le but est de faire une machine dédiée, donc si la manoeuvre est définitive, ce serai bien. Pour le test, je le fais sur ma machine de bureau.
Merci de me donner des précisions sur les 2 manoeuvres.
...
export ne change la variable d'environnement que pour la session
essai plutot un setenv
export est une commande bash/zsh & autre.
setenv une commande csh.

Les 2 font exactement la meme chose. A bon lecteur.

Et au passage je conseille de ne pas de passer le systeme en latin9 et de le garder en utf-8. Les vieilles applis incapable de faire de UTF8 ne merite pas ce retour en arriere.
20 jours plus tard
Je reprends la main du post de pascal_1212.

Pour ma part, j'ai besoin de ne pas être en UTF-8 pour lancer VDR sinon monsieur n'est pas content.

Donc, si vous avez une idée déja pour que la modif soit interne au terminal (dés que j'ai fermé le xterm, on en parje plus ...)

Et puis après pour une session totalement consacrée à VDR.

Bonne nuit les petits.
je me glisse dans la discussion pour parler de mon probleme.
J'utilise OpenNMS comme supervision réseau.
C'est une application Java éxécutée par Tomcat.

A certains moment le soft doit analyser des dates.
Or les dates qu'il récupère sont incorrectes :

2007-02-14 08:58:54,600 WARN [RTC Updater Pool-fiber3] DataUpdater: Failed to convert time -1 to java.util.Date, Setting current time instead
java.text.ParseException: Unparseable date: "mardi 13 f�vrier 2007 21 h 58 GMT"
at java.text.DateFormat.parse(DateFormat.java:335)
at org.opennms.netmgt.EventConstants.parseToDate(EventConstants.java:782)
at org.opennms.netmgt.rtc.DataUpdater.processEvent(DataUpdater.java:437)
at org.opennms.netmgt.rtc.DataUpdater.run(DataUpdater.java:513)
at org.opennms.core.concurrent.RunnableConsumerThreadPool$FiberThreadImpl.run(RunnableConsumerThreadPool.java:412)
at java.lang.Thread.run(Thread.java:595)



Comme vous le voyez, le caractere accentué de février n'est pas décodé correctement.
Ce probleme persiste si je modifie LANG avant de relancer le service opennms.

export LANG=fr_FR.ISO-8859-1

Pourriez vous me donner une piste pour trouver le point de configuration qui controle le format des dates récupérées par un tel soft.

Est-ce une config systeme, tomcat ou application ?

Désolé si je suis un peu hors sujet (c'est pas un forum java, ici !!!), mais je vous avoue que je ne trouve pas de piste efficace.
Java n'est pas iso, java est unicode. Me semble qu'il est UTF-16.
J'ai réussi à avoir un fonctionnement correct en modifiant LANG dans i18n (/etc/sysconfig).
LANG=en_US.iso88591

J'ai l'impression que c'est le iso88591 qui a un effet et pas le en_US.
Je retourne lire ma doc.

merci