J'ai copié quantité de fichiers d'une partition windows FAT32 à une
partition ext3 Linux et j'obtiens des caractères bizarres dans les noms
de fichiers à la place des accents.
3 cas possibles :
1) Le caractère n'est pas du tout reconnu et sous Konqueror j'ai un "?"
à la place du caractère spécial, ce qui fait planter la copie de fichier
avec cp pour cause "d'argument invalide"
2) Le caractère n'est pas reconnu par Konqueror et j'ai un petit carré à
la place, cependant je peux sans problème copier le fichier
3) Le caractère est reconnu par Konqueror mais pas dans un terminal (où
j'obtiens des "?" à la place des caractères spéciaux)
J'ai changé les fichiers du type 1) "à la main" car il n'y en avait pas
beaucoup par contre j'aimerais faire un script pour changer les fichiers
de type 2). Pourriez-vous m'aider ?
D'autre part est-il normal d'avoir des fichiers de type 3) ?
J'ai copié quantité de fichiers d'une partition windows FAT32 à une partition ext3 Linux et j'obtiens des caractères bizarres dans les noms>de fichiers à la place des accents.
3 cas possibles : 1) Le caractère n'est pas du tout reconnu et sous Konqueror j'ai un "?">à la place du caractère spécial, ce qui fait planter la copie de
fichier>avec cp pour cause "d'argument invalide" Moi j'ai tout simplement modifié le fichier /etc/sysconfig/i18n. Met
Oui simplement j'aimerai résoudre le problème une fois pour toute et changer directement le nom du fichier plutôt que de changer l'affichage...
3) Le caractère est reconnu par Konqueror mais pas dans un terminal (où>j'obtiens des "?" à la place des caractères spéciaux)
J'ai changé les fichiers du type 1) "à la main" car il n'y en avait pas>beaucoup par contre j'aimerais faire un script pour changer les
fichiers>de type 2). Pourriez-vous m'aider ? A titre d'exemple:
while ! [ "${maVariable:$i:1}" == "" ] do if ! [ "${maVariable:$i:1}" == "lettreAChanger" ] then mv ... fi let "i++" done
Voilà. Cela devrait t'aider. Guilhem.
Vu mon niveau en script et en codage de caractères, cela ne m'aide hélas pas beaucoup... Merci quand même !
J'ai copié quantité de fichiers d'une partition windows FAT32 à une
partition ext3 Linux et j'obtiens des caractères bizarres dans les
noms>de fichiers à la place des accents.
3 cas possibles :
1) Le caractère n'est pas du tout reconnu et sous Konqueror j'ai un
"?">à la place du caractère spécial, ce qui fait planter la copie de
fichier>avec cp pour cause "d'argument invalide"
Moi j'ai tout simplement modifié le fichier /etc/sysconfig/i18n. Met
J'ai copié quantité de fichiers d'une partition windows FAT32 à une partition ext3 Linux et j'obtiens des caractères bizarres dans les noms>de fichiers à la place des accents.
3 cas possibles : 1) Le caractère n'est pas du tout reconnu et sous Konqueror j'ai un "?">à la place du caractère spécial, ce qui fait planter la copie de
fichier>avec cp pour cause "d'argument invalide" Moi j'ai tout simplement modifié le fichier /etc/sysconfig/i18n. Met
Oui simplement j'aimerai résoudre le problème une fois pour toute et changer directement le nom du fichier plutôt que de changer l'affichage...
3) Le caractère est reconnu par Konqueror mais pas dans un terminal (où>j'obtiens des "?" à la place des caractères spéciaux)
J'ai changé les fichiers du type 1) "à la main" car il n'y en avait pas>beaucoup par contre j'aimerais faire un script pour changer les
fichiers>de type 2). Pourriez-vous m'aider ? A titre d'exemple:
while ! [ "${maVariable:$i:1}" == "" ] do if ! [ "${maVariable:$i:1}" == "lettreAChanger" ] then mv ... fi let "i++" done
Voilà. Cela devrait t'aider. Guilhem.
Vu mon niveau en script et en codage de caractères, cela ne m'aide hélas pas beaucoup... Merci quand même !
no_spam
On Sat, 21 Feb 2004 16:46:39 +0100, Pham wrote:
On Fri, 20 Feb 2004 12:30:41 +0100, no_spam
...
Le plus simple est de faire en sorte que le kernel utilise la page de code UTF8 systématiquement. On peut le faire en recompilant le kernel: CONFIG_NLS_DEFAULT="utf8" C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger mais l'encodage même des fichiers ! Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait: le kernel utilisera systématiquement l'encodage utf8 pour tous les syscalls qui utilisent ou renvoient des noms de fichiers. Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge par les applications.
On Sat, 21 Feb 2004 16:46:39 +0100, Pham wrote:
On Fri, 20 Feb 2004 12:30:41 +0100, no_spam
...
Le plus simple est de faire en sorte que le kernel utilise la page
de code UTF8 systématiquement.
On peut le faire en recompilant le kernel:
CONFIG_NLS_DEFAULT="utf8"
C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger
mais l'encodage même des fichiers !
Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait:
le kernel utilisera systématiquement l'encodage utf8 pour tous
les syscalls qui utilisent ou renvoient des noms de fichiers.
Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge
par les applications.
Le plus simple est de faire en sorte que le kernel utilise la page de code UTF8 systématiquement. On peut le faire en recompilant le kernel: CONFIG_NLS_DEFAULT="utf8" C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger mais l'encodage même des fichiers ! Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait: le kernel utilisera systématiquement l'encodage utf8 pour tous les syscalls qui utilisent ou renvoient des noms de fichiers. Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge par les applications.
Pham
On Sat, 21 Feb 2004 17:24:27 +0100, no_spam
Le plus simple est de faire en sorte que le kernel utilise la page de code UTF8 systématiquement. On peut le faire en recompilant le kernel: CONFIG_NLS_DEFAULT="utf8" C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger mais l'encodage même des fichiers ! Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait: le kernel utilisera systématiquement l'encodage utf8 pour tous les syscalls qui utilisent ou renvoient des noms de fichiers. Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge par les applications.
Ah ? pas mal comme astuce ! Est-ce que tout le monde fait comme ça ? Quels sont les inconvénients ou 'effets de bord' possibles ? En attendant j'ai réussi à reconvertir les noms de fichiers 'manuellement' en établissant une table de base pour 'tr'. C'est un peu bourrin comme tout mais comme il n'y a pas tant de caractères accentués que ça, c'est encore humainement faisable...
Merci !
On Sat, 21 Feb 2004 17:24:27 +0100, no_spam
Le plus simple est de faire en sorte que le kernel utilise la page
de code UTF8 systématiquement.
On peut le faire en recompilant le kernel:
CONFIG_NLS_DEFAULT="utf8"
C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais
corriger mais l'encodage même des fichiers !
Ca me gêne un peu de trimballer ces fichiers avec des noms
bizarres...
C'est exactement ce que ça fait:
le kernel utilisera systématiquement l'encodage utf8 pour tous
les syscalls qui utilisent ou renvoient des noms de fichiers.
Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge
par les applications.
Ah ? pas mal comme astuce !
Est-ce que tout le monde fait comme ça ?
Quels sont les inconvénients ou 'effets de bord' possibles ?
En attendant j'ai réussi à reconvertir les noms de fichiers
'manuellement' en établissant une table de base pour 'tr'. C'est un peu
bourrin comme tout mais comme il n'y a pas tant de caractères accentués
que ça, c'est encore humainement faisable...
Le plus simple est de faire en sorte que le kernel utilise la page de code UTF8 systématiquement. On peut le faire en recompilant le kernel: CONFIG_NLS_DEFAULT="utf8" C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger mais l'encodage même des fichiers ! Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait: le kernel utilisera systématiquement l'encodage utf8 pour tous les syscalls qui utilisent ou renvoient des noms de fichiers. Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge par les applications.
Ah ? pas mal comme astuce ! Est-ce que tout le monde fait comme ça ? Quels sont les inconvénients ou 'effets de bord' possibles ? En attendant j'ai réussi à reconvertir les noms de fichiers 'manuellement' en établissant une table de base pour 'tr'. C'est un peu bourrin comme tout mais comme il n'y a pas tant de caractères accentués que ça, c'est encore humainement faisable...
Merci !
no_spam
On Sat, 21 Feb 2004 17:46:41 +0100, Pham wrote:
On Sat, 21 Feb 2004 17:24:27 +0100, no_spam
Le plus simple est de faire en sorte que le kernel utilise la page de code UTF8 systématiquement. On peut le faire en recompilant le kernel: CONFIG_NLS_DEFAULT="utf8" C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger mais l'encodage même des fichiers ! Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait: le kernel utilisera systématiquement l'encodage utf8 pour tous les syscalls qui utilisent ou renvoient des noms de fichiers. Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge par les applications.
Ah ? pas mal comme astuce ! Est-ce que tout le monde fait comme ça ?
Je ne sais pas...
Quels sont les inconvénients ou 'effets de bord' possibles ?
Ca doit sans doute poser des problèmes aux applis qui ne savent traiter que de l'ascii 7 bits, mais il ne doit pas y en avoir des masses sur un système actuel... De même, il doit y avoir des problèmes si il y a des caractères encodés sur plusieurs octets, mais ça ne concerne pas l'ISO-latin 1 / 15, si je ne me trompe pas. Donc, attention pour ceux qui partagent des fichiers avec un Windows en version asiatique ou russe :-)
En attendant j'ai réussi à reconvertir les noms de fichiers 'manuellement' en établissant une table de base pour 'tr'. C'est un peu bourrin comme tout mais comme il n'y a pas tant de caractères accentués que ça, c'est encore humainement faisable...
Tant qu'on a à le faire qu'une fois, c'est relativement acceptable...
On Sat, 21 Feb 2004 17:46:41 +0100, Pham wrote:
On Sat, 21 Feb 2004 17:24:27 +0100, no_spam
Le plus simple est de faire en sorte que le kernel utilise la page
de code UTF8 systématiquement.
On peut le faire en recompilant le kernel:
CONFIG_NLS_DEFAULT="utf8"
C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais
corriger mais l'encodage même des fichiers !
Ca me gêne un peu de trimballer ces fichiers avec des noms
bizarres...
C'est exactement ce que ça fait:
le kernel utilisera systématiquement l'encodage utf8 pour tous
les syscalls qui utilisent ou renvoient des noms de fichiers.
Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge
par les applications.
Ah ? pas mal comme astuce !
Est-ce que tout le monde fait comme ça ?
Je ne sais pas...
Quels sont les inconvénients ou 'effets de bord' possibles ?
Ca doit sans doute poser des problèmes aux applis qui ne savent traiter
que de l'ascii 7 bits, mais il ne doit pas y en avoir des masses
sur un système actuel...
De même, il doit y avoir des problèmes si il y a des caractères
encodés sur plusieurs octets, mais ça ne concerne pas l'ISO-latin 1 / 15,
si je ne me trompe pas. Donc, attention pour ceux qui partagent
des fichiers avec un Windows en version asiatique ou russe :-)
En attendant j'ai réussi à reconvertir les noms de fichiers
'manuellement' en établissant une table de base pour 'tr'. C'est un peu
bourrin comme tout mais comme il n'y a pas tant de caractères accentués
que ça, c'est encore humainement faisable...
Tant qu'on a à le faire qu'une fois, c'est relativement acceptable...
Le plus simple est de faire en sorte que le kernel utilise la page de code UTF8 systématiquement. On peut le faire en recompilant le kernel: CONFIG_NLS_DEFAULT="utf8" C'est sans doute possible au run-time, mais je ne sais pas comment.
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger mais l'encodage même des fichiers ! Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait: le kernel utilisera systématiquement l'encodage utf8 pour tous les syscalls qui utilisent ou renvoient des noms de fichiers. Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge par les applications.
Ah ? pas mal comme astuce ! Est-ce que tout le monde fait comme ça ?
Je ne sais pas...
Quels sont les inconvénients ou 'effets de bord' possibles ?
Ca doit sans doute poser des problèmes aux applis qui ne savent traiter que de l'ascii 7 bits, mais il ne doit pas y en avoir des masses sur un système actuel... De même, il doit y avoir des problèmes si il y a des caractères encodés sur plusieurs octets, mais ça ne concerne pas l'ISO-latin 1 / 15, si je ne me trompe pas. Donc, attention pour ceux qui partagent des fichiers avec un Windows en version asiatique ou russe :-)
En attendant j'ai réussi à reconvertir les noms de fichiers 'manuellement' en établissant une table de base pour 'tr'. C'est un peu bourrin comme tout mais comme il n'y a pas tant de caractères accentués que ça, c'est encore humainement faisable...
Tant qu'on a à le faire qu'une fois, c'est relativement acceptable...
Bernard Déléchamp
[...]
Bon en fait l'erreur n'est pas dans le script, si je fais : echo "éèçàâêîô"| recode cp437..iso-8859-1
J'obtiens systématiquement : recode: Ambiguous output in step `CR-LF..data' et rien ne se passe...
Une petite visite dans «info recode» et essaie avec
recode cp437/...iso-8859.1
pour supprimer les erreurs sur CR/LF, ou en remplaçant cp437/ par cp850/ si le résultat n'est pas satisfaisant.
-- Dans la guerre, il y a une chose attractive : c'est le défilé de la victoire. L'emmerdant c'est avant. Michel Audiard
[...]
Bon en fait l'erreur n'est pas dans le script, si je fais :
echo "éèçàâêîô"| recode cp437..iso-8859-1
J'obtiens systématiquement :
recode: Ambiguous output in step `CR-LF..data' et rien ne se passe...
Une petite visite dans «info recode» et essaie avec
recode cp437/...iso-8859.1
pour supprimer les erreurs sur CR/LF, ou en remplaçant cp437/ par cp850/
si le résultat n'est pas satisfaisant.
--
Dans la guerre, il y a une chose attractive : c'est le défilé de la
victoire. L'emmerdant c'est avant.
Michel Audiard
Bon en fait l'erreur n'est pas dans le script, si je fais : echo "éèçàâêîô"| recode cp437..iso-8859-1
J'obtiens systématiquement : recode: Ambiguous output in step `CR-LF..data' et rien ne se passe...
Une petite visite dans «info recode» et essaie avec
recode cp437/...iso-8859.1
pour supprimer les erreurs sur CR/LF, ou en remplaçant cp437/ par cp850/ si le résultat n'est pas satisfaisant.
-- Dans la guerre, il y a une chose attractive : c'est le défilé de la victoire. L'emmerdant c'est avant. Michel Audiard
Pham
On Sat, 21 Feb 2004 21:10:28 +0100, Bernard Déléchamp
Bon en fait l'erreur n'est pas dans le script, si je fais : echo "éèçàâêîô"| recode cp437..iso-8859-1
J'obtiens systématiquement : recode: Ambiguous output in step `CR-LF..data' et rien ne se passe...
Une petite visite dans «info recode» et essaie avec
recode cp437/...iso-8859.1
pour supprimer les erreurs sur CR/LF, ou en remplaçant cp437/ par cp850/ si le résultat n'est pas satisfaisant.
Oui j'aurais dû dire que j'avais déjà essayé... si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1 ça ne donne qu'une ligne blanche et si j'essaye avec cp850/ ça me donne tout pleins de caractères bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum ça...)
On Sat, 21 Feb 2004 21:10:28 +0100, Bernard Déléchamp
Bon en fait l'erreur n'est pas dans le script, si je fais :
echo "éèçàâêîô"| recode cp437..iso-8859-1
J'obtiens systématiquement :
recode: Ambiguous output in step `CR-LF..data' et rien ne se
passe...
Une petite visite dans «info recode» et essaie avec
recode cp437/...iso-8859.1
pour supprimer les erreurs sur CR/LF, ou en remplaçant cp437/ par
cp850/ si le résultat n'est pas satisfaisant.
Oui j'aurais dû dire que j'avais déjà essayé...
si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1
ça ne donne qu'une ligne blanche
et si j'essaye avec cp850/ ça me donne tout pleins de caractères
bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum ça...)
On Sat, 21 Feb 2004 21:10:28 +0100, Bernard Déléchamp
Bon en fait l'erreur n'est pas dans le script, si je fais : echo "éèçàâêîô"| recode cp437..iso-8859-1
J'obtiens systématiquement : recode: Ambiguous output in step `CR-LF..data' et rien ne se passe...
Une petite visite dans «info recode» et essaie avec
recode cp437/...iso-8859.1
pour supprimer les erreurs sur CR/LF, ou en remplaçant cp437/ par cp850/ si le résultat n'est pas satisfaisant.
Oui j'aurais dû dire que j'avais déjà essayé... si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1 ça ne donne qu'une ligne blanche et si j'essaye avec cp850/ ça me donne tout pleins de caractères bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum ça...)
Bernard Déléchamp
Oui j'aurais dû dire que j'avais déjà essayé... si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1 ça ne donne qu'une ligne blanche et si j'essaye avec cp850/ ça me donne tout pleins de caractères bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum ça...)
Normal. Tu convertis des caractères iso-8850-1 (donc affichables) en d'autres qui ne le sont pas forcément. Si on affiche la sortie en hexadécimal, on n'obtient pas une ligne vierge :
Il faudrait faire l'essai avec des caractères *vraiment* issus d'une machine en cp437 ou cp850 pour s'en rendre compte.
Pas sûr d'avoir été très clair. Pour voir ce que ça donnerait, tu pourrais modifier le script donné initialement pour afficher les chaînes de caractères, sans faire le changement de nom :
IFS=$'tn' for ANCIEN in * ; do NOUVEAU=$(echo ${ANCIEN} | recode cp437/..iso-8859-1) echo ANCIEN="'"$ANCIEN"' NOUVEAU='"$NOUVEAU"'" done
Bon courage.
-- C'est évidemment un budget : il y a plein de chiffres dedans. George W. Bush
Oui j'aurais dû dire que j'avais déjà essayé...
si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1
ça ne donne qu'une ligne blanche
et si j'essaye avec cp850/ ça me donne tout pleins de caractères
bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum ça...)
Normal. Tu convertis des caractères iso-8850-1 (donc affichables) en
d'autres qui ne le sont pas forcément. Si on affiche la sortie en
hexadécimal, on n'obtient pas une ligne vierge :
Il faudrait faire l'essai avec des caractères *vraiment* issus d'une
machine en cp437 ou cp850 pour s'en rendre compte.
Pas sûr d'avoir été très clair. Pour voir ce que ça donnerait, tu
pourrais modifier le script donné initialement pour afficher les chaînes
de caractères, sans faire le changement de nom :
IFS=$'tn'
for ANCIEN in * ; do
NOUVEAU=$(echo ${ANCIEN} | recode cp437/..iso-8859-1)
echo ANCIEN="'"$ANCIEN"' NOUVEAU='"$NOUVEAU"'"
done
Bon courage.
--
C'est évidemment un budget : il y a plein de chiffres dedans.
George W. Bush
Oui j'aurais dû dire que j'avais déjà essayé... si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1 ça ne donne qu'une ligne blanche et si j'essaye avec cp850/ ça me donne tout pleins de caractères bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum ça...)
Normal. Tu convertis des caractères iso-8850-1 (donc affichables) en d'autres qui ne le sont pas forcément. Si on affiche la sortie en hexadécimal, on n'obtient pas une ligne vierge :
Il faudrait faire l'essai avec des caractères *vraiment* issus d'une machine en cp437 ou cp850 pour s'en rendre compte.
Pas sûr d'avoir été très clair. Pour voir ce que ça donnerait, tu pourrais modifier le script donné initialement pour afficher les chaînes de caractères, sans faire le changement de nom :
IFS=$'tn' for ANCIEN in * ; do NOUVEAU=$(echo ${ANCIEN} | recode cp437/..iso-8859-1) echo ANCIEN="'"$ANCIEN"' NOUVEAU='"$NOUVEAU"'" done
Bon courage.
-- C'est évidemment un budget : il y a plein de chiffres dedans. George W. Bush
Pham
On Sat, 21 Feb 2004 19:37:17 +0100, no_spam
Le plus simple est de faire en sorte que le kernel utilise la page> >> de code UTF8 systématiquement.
On peut le faire en recompilant le kernel: CONFIG_NLS_DEFAULT="utf8" C'est sans doute possible au run-time, mais je ne sais pas comment.> >
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger mais l'encodage même des fichiers ! Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait: le kernel utilisera systématiquement l'encodage utf8 pour tous les syscalls qui utilisent ou renvoient des noms de fichiers. Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge par les applications.
Quels sont les inconvénients ou 'effets de bord' possibles ?
Ca doit sans doute poser des problèmes aux applis qui ne savent traiter que de l'ascii 7 bits, mais il ne doit pas y en avoir des masses sur un système actuel... De même, il doit y avoir des problèmes si il y a des caractères encodés sur plusieurs octets, mais ça ne concerne pas l'ISO-latin 1 / 15, si je ne me trompe pas. Donc, attention pour ceux qui partagent des fichiers avec un Windows en version asiatique ou russe :-)
En attendant j'ai réussi à reconvertir les noms de fichiers 'manuellement' en établissant une table de base pour 'tr'. C'est un peu bourrin comme tout mais comme il n'y a pas tant de caractères accentués que ça, c'est encore humainement faisable...
Tant qu'on a à le faire qu'une fois, c'est relativement acceptable...
Merci pour tes éclaircissements !
On Sat, 21 Feb 2004 19:37:17 +0100, no_spam
Le plus simple est de faire en sorte que le kernel utilise la
page> >> de code UTF8 systématiquement.
On peut le faire en recompilant le kernel:
CONFIG_NLS_DEFAULT="utf8"
C'est sans doute possible au run-time, mais je ne sais pas
comment.> >
Oui mais ce n'est pas simplement l'affichage que je voudrais
corriger mais l'encodage même des fichiers !
Ca me gêne un peu de trimballer ces fichiers avec des noms
bizarres...
C'est exactement ce que ça fait:
le kernel utilisera systématiquement l'encodage utf8 pour tous
les syscalls qui utilisent ou renvoient des noms de fichiers.
Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge
par les applications.
Quels sont les inconvénients ou 'effets de bord' possibles ?
Ca doit sans doute poser des problèmes aux applis qui ne savent
traiter que de l'ascii 7 bits, mais il ne doit pas y en avoir des
masses sur un système actuel...
De même, il doit y avoir des problèmes si il y a des caractères
encodés sur plusieurs octets, mais ça ne concerne pas l'ISO-latin 1 /
15, si je ne me trompe pas. Donc, attention pour ceux qui partagent
des fichiers avec un Windows en version asiatique ou russe :-)
En attendant j'ai réussi à reconvertir les noms de fichiers
'manuellement' en établissant une table de base pour 'tr'. C'est un
peu bourrin comme tout mais comme il n'y a pas tant de caractères
accentués que ça, c'est encore humainement faisable...
Tant qu'on a à le faire qu'une fois, c'est relativement acceptable...
Le plus simple est de faire en sorte que le kernel utilise la page> >> de code UTF8 systématiquement.
On peut le faire en recompilant le kernel: CONFIG_NLS_DEFAULT="utf8" C'est sans doute possible au run-time, mais je ne sais pas comment.> >
Oui mais ce n'est pas simplement l'affichage que je voudrais corriger mais l'encodage même des fichiers ! Ca me gêne un peu de trimballer ces fichiers avec des noms bizarres...
C'est exactement ce que ça fait: le kernel utilisera systématiquement l'encodage utf8 pour tous les syscalls qui utilisent ou renvoient des noms de fichiers. Ca n'a aucun rapport avec l'affichage, qui lui est pris en charge par les applications.
Quels sont les inconvénients ou 'effets de bord' possibles ?
Ca doit sans doute poser des problèmes aux applis qui ne savent traiter que de l'ascii 7 bits, mais il ne doit pas y en avoir des masses sur un système actuel... De même, il doit y avoir des problèmes si il y a des caractères encodés sur plusieurs octets, mais ça ne concerne pas l'ISO-latin 1 / 15, si je ne me trompe pas. Donc, attention pour ceux qui partagent des fichiers avec un Windows en version asiatique ou russe :-)
En attendant j'ai réussi à reconvertir les noms de fichiers 'manuellement' en établissant une table de base pour 'tr'. C'est un peu bourrin comme tout mais comme il n'y a pas tant de caractères accentués que ça, c'est encore humainement faisable...
Tant qu'on a à le faire qu'une fois, c'est relativement acceptable...
Merci pour tes éclaircissements !
Pham
On Sun, 22 Feb 2004 09:45:24 +0100, Bernard Déléchamp
Oui j'aurais dû dire que j'avais déjà essayé... si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1 ça ne donne qu'une ligne blanche et si j'essaye avec cp850/ ça me donne tout pleins de caractères bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum ça...)
Normal. Tu convertis des caractères iso-8850-1 (donc affichables) en d'autres qui ne le sont pas forcément. Si on affiche la sortie en hexadécimal, on n'obtient pas une ligne vierge :
Il faudrait faire l'essai avec des caractères *vraiment* issus d'une machine en cp437 ou cp850 pour s'en rendre compte.
Pas sûr d'avoir été très clair. Pour voir ce que ça donnerait, tu pourrais modifier le script donné initialement pour afficher les chaînes de caractères, sans faire le changement de nom :
IFS=$'tn' for ANCIEN in * ; do NOUVEAU=$(echo ${ANCIEN} | recode cp437/..iso-8859-1) echo ANCIEN="'"$ANCIEN"' NOUVEAU='"$NOUVEAU"'" done
Bon courage.
Le problème étant qu'apparemment il y avait des fichiers corrects mixés avec des fichiers incorrects (ne me demande pas comment Windows a magouillé son affaire !). Donc le script ne marchait pas sur les fichiers codés correctement ! Il aurait fallu détecter avant l'utilisation de recode si le fichier était codé correctement ou pas... Cela dépasse de loin mes compétences... Mais j'ai utilisé l'autre solution proposé par un contributeur, à savoir utiliser 'tr' et une table de correspondance pour modidifier les fichiers. Comme il n'y a pas trop d'accents possibles dans la langue française, cela était encore humainement faisables...
Merci pour ton aide néanmoins !
On Sun, 22 Feb 2004 09:45:24 +0100, Bernard Déléchamp
Oui j'aurais dû dire que j'avais déjà essayé...
si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1
ça ne donne qu'une ligne blanche
et si j'essaye avec cp850/ ça me donne tout pleins de caractères
bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum
ça...)
Normal. Tu convertis des caractères iso-8850-1 (donc affichables) en
d'autres qui ne le sont pas forcément. Si on affiche la sortie en
hexadécimal, on n'obtient pas une ligne vierge :
Il faudrait faire l'essai avec des caractères *vraiment* issus d'une
machine en cp437 ou cp850 pour s'en rendre compte.
Pas sûr d'avoir été très clair. Pour voir ce que ça donnerait, tu
pourrais modifier le script donné initialement pour afficher les
chaînes de caractères, sans faire le changement de nom :
IFS=$'tn'
for ANCIEN in * ; do
NOUVEAU=$(echo ${ANCIEN} | recode cp437/..iso-8859-1)
echo ANCIEN="'"$ANCIEN"' NOUVEAU='"$NOUVEAU"'"
done
Bon courage.
Le problème étant qu'apparemment il y avait des fichiers corrects mixés
avec des fichiers incorrects (ne me demande pas comment Windows a
magouillé son affaire !). Donc le script ne marchait pas sur les
fichiers codés correctement !
Il aurait fallu détecter avant l'utilisation de recode si le fichier
était codé correctement ou pas...
Cela dépasse de loin mes compétences...
Mais j'ai utilisé l'autre solution proposé par un contributeur, à savoir
utiliser 'tr' et une table de correspondance pour modidifier les
fichiers. Comme il n'y a pas trop d'accents possibles dans la langue
française, cela était encore humainement faisables...
On Sun, 22 Feb 2004 09:45:24 +0100, Bernard Déléchamp
Oui j'aurais dû dire que j'avais déjà essayé... si je tape : echo "éèçàâêîô"| recode cp437/..iso-8859-1 ça ne donne qu'une ligne blanche et si j'essaye avec cp850/ ça me donne tout pleins de caractères bizarres... genre ÚÞþÓÔÛ¯¶ (pas sûr que ça passe dans le forum ça...)
Normal. Tu convertis des caractères iso-8850-1 (donc affichables) en d'autres qui ne le sont pas forcément. Si on affiche la sortie en hexadécimal, on n'obtient pas une ligne vierge :
Il faudrait faire l'essai avec des caractères *vraiment* issus d'une machine en cp437 ou cp850 pour s'en rendre compte.
Pas sûr d'avoir été très clair. Pour voir ce que ça donnerait, tu pourrais modifier le script donné initialement pour afficher les chaînes de caractères, sans faire le changement de nom :
IFS=$'tn' for ANCIEN in * ; do NOUVEAU=$(echo ${ANCIEN} | recode cp437/..iso-8859-1) echo ANCIEN="'"$ANCIEN"' NOUVEAU='"$NOUVEAU"'" done
Bon courage.
Le problème étant qu'apparemment il y avait des fichiers corrects mixés avec des fichiers incorrects (ne me demande pas comment Windows a magouillé son affaire !). Donc le script ne marchait pas sur les fichiers codés correctement ! Il aurait fallu détecter avant l'utilisation de recode si le fichier était codé correctement ou pas... Cela dépasse de loin mes compétences... Mais j'ai utilisé l'autre solution proposé par un contributeur, à savoir utiliser 'tr' et une table de correspondance pour modidifier les fichiers. Comme il n'y a pas trop d'accents possibles dans la langue française, cela était encore humainement faisables...
