Bonjour,
J'ai un soucis récurent qui touche dolphin, mais aussi d'autres
applications basées seulement sur QT4 et non sur KDE4...
Dans certains répertoires, j'ai des fichier avec des noms pourris
(iso8859-1 mélangé avec de l'UTF-8 ou bien des fichiers issue d u MacOSX
qui semblent être dans un autre encodage...).
En console je parviens à les renommer sans soucis, un simple mv et l e
tour et joué...
Cependant, j'aimerai pouvoir les utiliser tel quel sans avoir à reno mmer
quelques 100aine de fichiers à la mano comme c'était le cas sou s KDE 3.5
ou bien pouvoir les renommer à partir de l'interface graphique.
Est-ce que quelqu'un rencontre le même genre de problème et à trouvé un
substitue ?
Par ailleurs, j'aimerai faire un bug report de ce problème, mais je ne
sais pas quel paquet est responsable de ce problème...
Bonjour,
J'ai un soucis récurent qui touche dolphin, mais aussi d'autres
applications basées seulement sur QT4 et non sur KDE4...
Dans certains répertoires, j'ai des fichier avec des noms pourris
(iso8859-1 mélangé avec de l'UTF-8 ou bien des fichiers issue d u MacOSX
qui semblent être dans un autre encodage...).
En console je parviens à les renommer sans soucis, un simple mv et l e
tour et joué...
Cependant, j'aimerai pouvoir les utiliser tel quel sans avoir à reno mmer
quelques 100aine de fichiers à la mano comme c'était le cas sou s KDE 3.5
ou bien pouvoir les renommer à partir de l'interface graphique.
Est-ce que quelqu'un rencontre le même genre de problème et à trouvé un
substitue ?
Par ailleurs, j'aimerai faire un bug report de ce problème, mais je ne
sais pas quel paquet est responsable de ce problème...
Bonjour,
J'ai un soucis récurent qui touche dolphin, mais aussi d'autres
applications basées seulement sur QT4 et non sur KDE4...
Dans certains répertoires, j'ai des fichier avec des noms pourris
(iso8859-1 mélangé avec de l'UTF-8 ou bien des fichiers issue d u MacOSX
qui semblent être dans un autre encodage...).
En console je parviens à les renommer sans soucis, un simple mv et l e
tour et joué...
Cependant, j'aimerai pouvoir les utiliser tel quel sans avoir à reno mmer
quelques 100aine de fichiers à la mano comme c'était le cas sou s KDE 3.5
ou bien pouvoir les renommer à partir de l'interface graphique.
Est-ce que quelqu'un rencontre le même genre de problème et à trouvé un
substitue ?
Par ailleurs, j'aimerai faire un bug report de ce problème, mais je ne
sais pas quel paquet est responsable de ce problème...
newbeewan, mercredi 27 mai 2009, 18:35:12 CESTBonjour,
’soir,J'ai un soucis récurent qui touche dolphin, mais aussi d'autres
applications basées seulement sur QT4 et non sur KDE4...
Qt, t minuscule, avec une majuscule, c’est QuickTime™…Dans certains répertoires, j'ai des fichier avec des noms pourris
(iso8859-1 mélangé avec de l'UTF-8 ou bien des fichiers issue du MacOSX
qui semblent être dans un autre encodage...).
En console je parviens à les renommer sans soucis, un simple mv et le
tour et joué...
Cependant, j'aimerai pouvoir les utiliser tel quel sans avoir à renommer
quelques 100aine de fichiers à la mano comme c'était le cas sous KDE 3.5
ou bien pouvoir les renommer à partir de l'interface graphique.
Est-ce que quelqu'un rencontre le même genre de problème et à trouvé un
substitue ?
Par ailleurs, j'aimerai faire un bug report de ce problème, mais je ne
sais pas quel paquet est responsable de ce problème...
Ça n’est pas un bogue ! C’est un problème avec la couche 8 du
modèle OSI.
Un nom de fichier, c’est juste une suite d’octets différents
de 057 (/) et 000 (sauf pour marquer la fin). Les outils qui les
affichent et les manipulent (dolphin, xterm, bash, cp…), soit
s’en fichent, soit doivent essayer de les interpréter pour
afficher de jolis dessins (caractères) que l’utilisateur pourra
comprendre.
Cette interprétation est le « charset » d’une « locale ».
P.ex. en UTF-8, la séquence 303251 sera affichée par le
dessin d’un e avec un accent aigu (é), alors qu’en Latin-9, la
même séquence d’octets sera affichée par le dessin d’un A avec
un tilde suivi d’un c dans un rond (é). Si tu mélanges les
interprétations (les locales), comment veux-tu que l’outil
devine laquelle utiliser ? L’outil ne peut utiliser que la
locale ou le charset courant.
Tu vas me dire que é, ça ne fera jamais partie d’un de tes
noms de fichier, donc que ce n’est pas Latin-9 (ou 1) qu’il faut
utiliser comme interprétation mais UTF-8.
Mais comment l’outil peut-il savoir que é ne peut pas faire
partie d’un nom de fichier ? Parce ce ne sont pas des caractères
français ? Dans ce cas, il doit savoir que tu préfères le
français. Ce qui tombe bien puisque c’est ce que ta locale lui
dit et c’est justement ta locale qu’il utilise… Et puis est-ce
que tu ne vas pas ensuite te plaindre que le nom des fichiers de
ton cours de coréen ne s’affichent pas comme il faut ?
Ah si, il y a une solution technique : que le charset du nom
de fichier soit une méta-donnée du fichier. Mais ce n’est pas
demain la veille pour que ça arrive, d’abord parce que c’est
redondant avec la locale dans 99,999999% des cas et aussi parce
que ce n’est même pas une méta-donnée du système de fichiers
entier (c’est une option de montage pour certains).
La solution est de rester propre (un seul charset, p.ex.
UTF-8) et d’utiliser les outils convenables (comme convmv,
paquet de même nom) pour le rester.
newbeewan, mercredi 27 mai 2009, 18:35:12 CEST
Bonjour,
’soir,
J'ai un soucis récurent qui touche dolphin, mais aussi d'autres
applications basées seulement sur QT4 et non sur KDE4...
Qt, t minuscule, avec une majuscule, c’est QuickTime™…
Dans certains répertoires, j'ai des fichier avec des noms pourris
(iso8859-1 mélangé avec de l'UTF-8 ou bien des fichiers issue du MacOSX
qui semblent être dans un autre encodage...).
En console je parviens à les renommer sans soucis, un simple mv et le
tour et joué...
Cependant, j'aimerai pouvoir les utiliser tel quel sans avoir à renommer
quelques 100aine de fichiers à la mano comme c'était le cas sous KDE 3.5
ou bien pouvoir les renommer à partir de l'interface graphique.
Est-ce que quelqu'un rencontre le même genre de problème et à trouvé un
substitue ?
Par ailleurs, j'aimerai faire un bug report de ce problème, mais je ne
sais pas quel paquet est responsable de ce problème...
Ça n’est pas un bogue ! C’est un problème avec la couche 8 du
modèle OSI.
Un nom de fichier, c’est juste une suite d’octets différents
de 057 (/) et 000 (sauf pour marquer la fin). Les outils qui les
affichent et les manipulent (dolphin, xterm, bash, cp…), soit
s’en fichent, soit doivent essayer de les interpréter pour
afficher de jolis dessins (caractères) que l’utilisateur pourra
comprendre.
Cette interprétation est le « charset » d’une « locale ».
P.ex. en UTF-8, la séquence 303251 sera affichée par le
dessin d’un e avec un accent aigu (é), alors qu’en Latin-9, la
même séquence d’octets sera affichée par le dessin d’un A avec
un tilde suivi d’un c dans un rond (é). Si tu mélanges les
interprétations (les locales), comment veux-tu que l’outil
devine laquelle utiliser ? L’outil ne peut utiliser que la
locale ou le charset courant.
Tu vas me dire que é, ça ne fera jamais partie d’un de tes
noms de fichier, donc que ce n’est pas Latin-9 (ou 1) qu’il faut
utiliser comme interprétation mais UTF-8.
Mais comment l’outil peut-il savoir que é ne peut pas faire
partie d’un nom de fichier ? Parce ce ne sont pas des caractères
français ? Dans ce cas, il doit savoir que tu préfères le
français. Ce qui tombe bien puisque c’est ce que ta locale lui
dit et c’est justement ta locale qu’il utilise… Et puis est-ce
que tu ne vas pas ensuite te plaindre que le nom des fichiers de
ton cours de coréen ne s’affichent pas comme il faut ?
Ah si, il y a une solution technique : que le charset du nom
de fichier soit une méta-donnée du fichier. Mais ce n’est pas
demain la veille pour que ça arrive, d’abord parce que c’est
redondant avec la locale dans 99,999999% des cas et aussi parce
que ce n’est même pas une méta-donnée du système de fichiers
entier (c’est une option de montage pour certains).
La solution est de rester propre (un seul charset, p.ex.
UTF-8) et d’utiliser les outils convenables (comme convmv,
paquet de même nom) pour le rester.
newbeewan, mercredi 27 mai 2009, 18:35:12 CESTBonjour,
’soir,J'ai un soucis récurent qui touche dolphin, mais aussi d'autres
applications basées seulement sur QT4 et non sur KDE4...
Qt, t minuscule, avec une majuscule, c’est QuickTime™…Dans certains répertoires, j'ai des fichier avec des noms pourris
(iso8859-1 mélangé avec de l'UTF-8 ou bien des fichiers issue du MacOSX
qui semblent être dans un autre encodage...).
En console je parviens à les renommer sans soucis, un simple mv et le
tour et joué...
Cependant, j'aimerai pouvoir les utiliser tel quel sans avoir à renommer
quelques 100aine de fichiers à la mano comme c'était le cas sous KDE 3.5
ou bien pouvoir les renommer à partir de l'interface graphique.
Est-ce que quelqu'un rencontre le même genre de problème et à trouvé un
substitue ?
Par ailleurs, j'aimerai faire un bug report de ce problème, mais je ne
sais pas quel paquet est responsable de ce problème...
Ça n’est pas un bogue ! C’est un problème avec la couche 8 du
modèle OSI.
Un nom de fichier, c’est juste une suite d’octets différents
de 057 (/) et 000 (sauf pour marquer la fin). Les outils qui les
affichent et les manipulent (dolphin, xterm, bash, cp…), soit
s’en fichent, soit doivent essayer de les interpréter pour
afficher de jolis dessins (caractères) que l’utilisateur pourra
comprendre.
Cette interprétation est le « charset » d’une « locale ».
P.ex. en UTF-8, la séquence 303251 sera affichée par le
dessin d’un e avec un accent aigu (é), alors qu’en Latin-9, la
même séquence d’octets sera affichée par le dessin d’un A avec
un tilde suivi d’un c dans un rond (é). Si tu mélanges les
interprétations (les locales), comment veux-tu que l’outil
devine laquelle utiliser ? L’outil ne peut utiliser que la
locale ou le charset courant.
Tu vas me dire que é, ça ne fera jamais partie d’un de tes
noms de fichier, donc que ce n’est pas Latin-9 (ou 1) qu’il faut
utiliser comme interprétation mais UTF-8.
Mais comment l’outil peut-il savoir que é ne peut pas faire
partie d’un nom de fichier ? Parce ce ne sont pas des caractères
français ? Dans ce cas, il doit savoir que tu préfères le
français. Ce qui tombe bien puisque c’est ce que ta locale lui
dit et c’est justement ta locale qu’il utilise… Et puis est-ce
que tu ne vas pas ensuite te plaindre que le nom des fichiers de
ton cours de coréen ne s’affichent pas comme il faut ?
Ah si, il y a une solution technique : que le charset du nom
de fichier soit une méta-donnée du fichier. Mais ce n’est pas
demain la veille pour que ça arrive, d’abord parce que c’est
redondant avec la locale dans 99,999999% des cas et aussi parce
que ce n’est même pas une méta-donnée du système de fichiers
entier (c’est une option de montage pour certains).
La solution est de rester propre (un seul charset, p.ex.
UTF-8) et d’utiliser les outils convenables (comme convmv,
paquet de même nom) pour le rester.
[â¦]
Je reçois régulièrement des fichiers de différentes s ources avec des
encodages dans les noms plus ou moins pourris (principalement Mac,
cp850, iso8859-1, ou un mix entre plusieurs encodages) et ça m'est p lus
rapide de remettre les accents via le "renommage" de mon navigateur de
fichier plutôt que de tâtonner avec convmv...
Auparavant dans KDE 3.5, je n'avais pas de soucis pour les renommer Ã
partir de Konqueror ancienne version, ce qui n'est plus le cas avec
dolphin d'où mon interrogation...
Du point de vue de l'utilisateur que je suis, c'est une régression
alors
que du point de vue de la norme, c'est plus stricte,
et je préfèrerais
dans ce cas là que l'utilisateur prime ! d'où ma volonté d e faire un bug
report pour que dolphin ou QT soit un peu plus tout terrain...
[â¦]
Je reçois régulièrement des fichiers de différentes s ources avec des
encodages dans les noms plus ou moins pourris (principalement Mac,
cp850, iso8859-1, ou un mix entre plusieurs encodages) et ça m'est p lus
rapide de remettre les accents via le "renommage" de mon navigateur de
fichier plutôt que de tâtonner avec convmv...
Auparavant dans KDE 3.5, je n'avais pas de soucis pour les renommer Ã
partir de Konqueror ancienne version, ce qui n'est plus le cas avec
dolphin d'où mon interrogation...
Du point de vue de l'utilisateur que je suis, c'est une régression
alors
que du point de vue de la norme, c'est plus stricte,
et je préfèrerais
dans ce cas là que l'utilisateur prime ! d'où ma volonté d e faire un bug
report pour que dolphin ou QT soit un peu plus tout terrain...
[â¦]
Je reçois régulièrement des fichiers de différentes s ources avec des
encodages dans les noms plus ou moins pourris (principalement Mac,
cp850, iso8859-1, ou un mix entre plusieurs encodages) et ça m'est p lus
rapide de remettre les accents via le "renommage" de mon navigateur de
fichier plutôt que de tâtonner avec convmv...
Auparavant dans KDE 3.5, je n'avais pas de soucis pour les renommer Ã
partir de Konqueror ancienne version, ce qui n'est plus le cas avec
dolphin d'où mon interrogation...
Du point de vue de l'utilisateur que je suis, c'est une régression
alors
que du point de vue de la norme, c'est plus stricte,
et je préfèrerais
dans ce cas là que l'utilisateur prime ! d'où ma volonté d e faire un bug
report pour que dolphin ou QT soit un peu plus tout terrain...