Ubuntu 12.10 iconv ne supporte tjs pas UTF-8-MAC ?
45 réponses
Une Bévue
si je fais :
$ iconv -l | grep MAC
CSISO111ECMACYRILLIC//
CSMACINTOSH//
ECMACYRILLIC//
MAC-CENTRALEUROPE//
MAC-CYRILLIC//
MAC-IS//
MAC-SAMI//
MAC-UK//
MAC//
MACCYRILLIC//
MACINTOSH//
MACIS//
MACUK//
MACUKRAINIAN//
MS-MAC-CYRILLIC//
MSMACCYRILLIC//
il n'est pas listé UTF-8-MAC, pourtant déjà en 2004 quelqu'un le
réclamait pour Debian :
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272727>
c'est génant pour faire du rsync car un fichier :
cachée.html (sur mac)
devient :
cacheé.html (sur linux)
(l'accent aigu a été déplacé au caractère suivant)
aussi rsync "pense" ne pas avoir up/downloadé le fichier...
Le Mon, 19 Nov 2012 18:22:10 +0100, Une Bévue a écrit :
bon là, je ne sais pas ce qui va se passer avec les signes diacritiques compte tenu du fait que mon FAI est free et que j'utilise Thunderbird sous Xubuntu, mais cet exemple précis j'ai : "Prazak Quartet" disons US ascii sur Xubuntu le signe diacritique qui ressemble à un v est sur le z alors que sur mon mac il est sur le a qui précède de même l'accent aigu sur le a qui suit est sur le z sur mac.
detox ?
Le Mon, 19 Nov 2012 18:22:10 +0100, Une Bévue a écrit :
bon là, je ne sais pas ce qui va se passer avec les signes diacritiques
compte tenu du fait que mon FAI est free et que j'utilise Thunderbird
sous Xubuntu, mais cet exemple précis j'ai : "Prazak Quartet" disons US
ascii sur Xubuntu le signe diacritique qui ressemble à un v est sur le z
alors que sur mon mac il est sur le a qui précède de même l'accent aigu
sur le a qui suit est sur le z sur mac.
Le Mon, 19 Nov 2012 18:22:10 +0100, Une Bévue a écrit :
bon là, je ne sais pas ce qui va se passer avec les signes diacritiques compte tenu du fait que mon FAI est free et que j'utilise Thunderbird sous Xubuntu, mais cet exemple précis j'ai : "Prazak Quartet" disons US ascii sur Xubuntu le signe diacritique qui ressemble à un v est sur le z alors que sur mon mac il est sur le a qui précède de même l'accent aigu sur le a qui suit est sur le z sur mac.
detox ?
Doug713705
Le 19-11-2012, Une Bévue nous expliquait dans fr.comp.os.linux.configuration :
Le 19/11/2012 19:29, jp willm a écrit :
Depuis, je suis tranquille.
c'est sûr, mais c'est du boulot...
Non, si tu le souhaites c'est _une_ seule ligne de commande pour tout le système de fichiers.
man detox
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 19-11-2012, Une Bévue nous expliquait dans fr.comp.os.linux.configuration :
Le 19/11/2012 19:29, jp willm a écrit :
Depuis, je suis tranquille.
c'est sûr, mais c'est du boulot...
Non, si tu le souhaites c'est _une_ seule ligne de commande pour tout
le système de fichiers.
man detox
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 19-11-2012, Une Bévue nous expliquait dans fr.comp.os.linux.configuration :
Le 19/11/2012 19:29, jp willm a écrit :
Depuis, je suis tranquille.
c'est sûr, mais c'est du boulot...
Non, si tu le souhaites c'est _une_ seule ligne de commande pour tout le système de fichiers.
man detox
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
jp willm
Le 19/11/2012 19:41, Une Bévue a écrit :
Le 19/11/2012 19:29, jp willm a écrit :
Depuis, je suis tranquille.
c'est sûr, mais c'est du boulot...
Meuh non, une fois que tu connais un peu, tu prépares tes réglages en 5 secondes et tu lances le renommage.
J'utilise pyrenamer, car je suis un peu fainéant :o)
Une Bévue , dans le message <50aa6ac1$0$16484$, a écrit :
ben qu'en j'enregistre un cd par exemple du "Pražák Quartet" je ne vais pas aller changer le nom du dossier, c'est automatique point barre.
Si ton truc automatique n'a pas une option pour ne nommer les fichiers qu'avec les caractères portables, il est bon pour la poubelle.
Nicolas George
Erwan David , dans le message , a écrit :
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Rien du tout. Il écrit des octets sur sa sortie standard. Octets qui seront peut-être plus tard interprétés comme des caractères par un autre logiciel connecté à la sortie standard, mais c'est une autre histoire.
Non ce n'est pas une suite d'octest, c'est une suite de caractères,
Ce n'est pas l'affirmer qui le rendra vrai.
idem pour un open.
Si, précisément. open fonctionne avec un tableau d'octets, avec pour seule convention que l'octet de valeur 0 indique la fin, et l'octet de valeur 47 indique la séparation entre noms de répertoires. Il ne tient absolument pas compte d'histoires d'encodage.
Erwan David , dans le message <m2a9udh59k.fsf@rail.eu.org>, a écrit :
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Rien du tout. Il écrit des octets sur sa sortie standard. Octets qui seront
peut-être plus tard interprétés comme des caractères par un autre logiciel
connecté à la sortie standard, mais c'est une autre histoire.
Non ce n'est pas une suite d'octest, c'est une suite de caractères,
Ce n'est pas l'affirmer qui le rendra vrai.
idem
pour un open.
Si, précisément. open fonctionne avec un tableau d'octets, avec pour seule
convention que l'octet de valeur 0 indique la fin, et l'octet de valeur 47
indique la séparation entre noms de répertoires. Il ne tient absolument pas
compte d'histoires d'encodage.
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?
Rien du tout. Il écrit des octets sur sa sortie standard. Octets qui seront peut-être plus tard interprétés comme des caractères par un autre logiciel connecté à la sortie standard, mais c'est une autre histoire.
Non ce n'est pas une suite d'octest, c'est une suite de caractères,
Ce n'est pas l'affirmer qui le rendra vrai.
idem pour un open.
Si, précisément. open fonctionne avec un tableau d'octets, avec pour seule convention que l'octet de valeur 0 indique la fin, et l'octet de valeur 47 indique la séparation entre noms de répertoires. Il ne tient absolument pas compte d'histoires d'encodage.
Une Bévue
Le 20/11/2012 19:52, Nicolas George a écrit :
Si, précisément. open fonctionne avec un tableau d'octets, avec pour seule convention que l'octet de valeur 0 indique la fin, et l'octet de valeur 47 indique la séparation entre noms de répertoires. Il ne tient absolument pas compte d'histoires d'encodage.
ben alors pourquoi rsync se gourre ?
Le 20/11/2012 19:52, Nicolas George a écrit :
Si, précisément. open fonctionne avec un tableau d'octets, avec pour seule
convention que l'octet de valeur 0 indique la fin, et l'octet de valeur 47
indique la séparation entre noms de répertoires. Il ne tient absolument pas
compte d'histoires d'encodage.
Si, précisément. open fonctionne avec un tableau d'octets, avec pour seule convention que l'octet de valeur 0 indique la fin, et l'octet de valeur 47 indique la séparation entre noms de répertoires. Il ne tient absolument pas compte d'histoires d'encodage.
ben alors pourquoi rsync se gourre ?
Nicolas George
Une Bévue , dans le message <50acf479$0$6481$, a écrit :
ben alors pourquoi rsync se gourre ?
Probablement parce que tu utilises des filesystems pourris.
Une Bévue , dans le message <50acf479$0$6481$426a74cc@news.free.fr>, a
écrit :
ben alors pourquoi rsync se gourre ?
Probablement parce que tu utilises des filesystems pourris.
Une Bévue , dans le message <50acf479$0$6481$, a écrit :
ben alors pourquoi rsync se gourre ?
Probablement parce que tu utilises des filesystems pourris.
Une Bévue
Le 20/11/2012 19:50, Nicolas George a écrit :
Si ton truc automatique n'a pas une option pour ne nommer les fichiers qu'avec les caractères portables, il est bon pour la poubelle.
ce n'est pas histoire d'option mais d'héritage et d'histoire. mon truc ne génère que des fichiers nommés en US-ASCII, sans espace, mais pour ceux du passé issu de téléchargements sans contrôle auto (save as tout court). ce n'est pas si évident de renommer les fichiers/dossiers car les liens *internes (href=...) (c'est du html) sont perdus. je pense à le faire, mais un peu plus tard.
quand à Prazel Quartet, ce que j'ai dit est faux, les signes diacritiques sont préservés --par scp-- (donc avec source = Mac os x ml, destination = linux xubuntu 12.10)
bon, c'est tout neuf, il faut que j'y regarde de plus près, car je trouve étrange que scp s'en sorte tout seul, et qu'rsync ait besoin d'iconv...
quand à la manière dont mon script détectait la commande passée par le serveur (un grep / tail sur "TODO :", j'ai changé ça, j'envoie un fichier xml avec tout ce qu'il faut.
Le 20/11/2012 19:50, Nicolas George a écrit :
Si ton truc automatique n'a pas une option pour ne nommer les fichiers
qu'avec les caractères portables, il est bon pour la poubelle.
ce n'est pas histoire d'option mais d'héritage et d'histoire.
mon truc ne génère que des fichiers nommés en US-ASCII, sans espace,
mais pour ceux du passé issu de téléchargements sans contrôle auto (save
as tout court).
ce n'est pas si évident de renommer les fichiers/dossiers car les liens
*internes (href=...) (c'est du html) sont perdus.
je pense à le faire, mais un peu plus tard.
quand à Prazel Quartet, ce que j'ai dit est faux, les signes
diacritiques sont préservés --par scp-- (donc avec source = Mac os x ml,
destination = linux xubuntu 12.10)
bon, c'est tout neuf, il faut que j'y regarde de plus près, car je
trouve étrange que scp s'en sorte tout seul, et qu'rsync ait besoin
d'iconv...
quand à la manière dont mon script détectait la commande passée par le
serveur (un grep / tail sur "TODO :", j'ai changé ça, j'envoie un
fichier xml avec tout ce qu'il faut.
Si ton truc automatique n'a pas une option pour ne nommer les fichiers qu'avec les caractères portables, il est bon pour la poubelle.
ce n'est pas histoire d'option mais d'héritage et d'histoire. mon truc ne génère que des fichiers nommés en US-ASCII, sans espace, mais pour ceux du passé issu de téléchargements sans contrôle auto (save as tout court). ce n'est pas si évident de renommer les fichiers/dossiers car les liens *internes (href=...) (c'est du html) sont perdus. je pense à le faire, mais un peu plus tard.
quand à Prazel Quartet, ce que j'ai dit est faux, les signes diacritiques sont préservés --par scp-- (donc avec source = Mac os x ml, destination = linux xubuntu 12.10)
bon, c'est tout neuf, il faut que j'y regarde de plus près, car je trouve étrange que scp s'en sorte tout seul, et qu'rsync ait besoin d'iconv...
quand à la manière dont mon script détectait la commande passée par le serveur (un grep / tail sur "TODO :", j'ai changé ça, j'envoie un fichier xml avec tout ce qu'il faut.
Une Bévue
Le 21/11/2012 16:36, Nicolas George a écrit :
Probablement parce que tu utilises des filesystems pourris.
faut le dire à Apple...
Le 21/11/2012 16:36, Nicolas George a écrit :
Probablement parce que tu utilises des filesystems pourris.
