Ubuntu 12.10 iconv ne supporte tjs pas UTF-8-MAC ?

Le
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'2727>

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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
  • Ubuntu Sudio est une distribution Linux orientée multimédia.
  • Ubuntu est une distribution Linux libre et gratuite basée sur Debian.
Vos réponses Page 1 / 5
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #24973202
Une Bévue , dans le message écrit :
il n'est pas listé UTF-8-MAC



Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a
aucune raison d'être supporté par iconv.

Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode
sous forme canonique décomposée, parce que apple ne pouvait pas décemment
utiliser la forme canonique composée comme tout le monde, ça aurait rendu
l'interopérabilité trop facile.

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)



rsync est un outil Unix, s'il travaille avec des filesystems décents (pas
FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.

Accessoirement :

# 3.276 Portable Filename Character Set
#
# The set of characters from which portable filenames are constructed.
#
# A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
# a b c d e f g h i j k l m n o p q r s t u v w x y z
# 0 1 2 3 4 5 6 7 8 9 . _ -
#
# The last three characters are the <period>, <underscore>, and <hyphen>
# characters, respectively.

Sinon, c'est que tu cherches les ennuis.
Erwan David
Le #24973302
Nicolas George
Une Bévue , dans le message écrit :
il n'est pas listé UTF-8-MAC



Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a
aucune raison d'être supporté par iconv.

Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode
sous forme canonique décomposée, parce que apple ne pouvait pas décemment
utiliser la forme canonique composée comme tout le monde, ça aurait rendu
l'interopérabilité trop facile.

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)



rsync est un outil Unix, s'il travaille avec des filesystems décents (pas
FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.




Certes, mais l'option de rsync sers à ce que le nom de fichier soit
correctement converti selon les FS de départ et d'arrivée.

--
Les simplifications c'est trop compliqué
Une Bévue
Le #24973912
Le 18/11/12 20:59, Nicolas George a écrit :
il n'est pas listé UTF-8-MAC


Pour autant que je sache, ce n'est pas le nom d'un encodage, donc ça n'a
aucune raison d'être supporté par iconv.



ben si je lis la FAQ You can avoid a charset problem by passing an appropriate --iconv option
to rsync that tells it what character-set the source files are, and what
character-set the destination files get stored in. For instance, the
above Mac OS X problem would be dealt with by using
--iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac
OS X iconv in which all characters are decomposed).

et sur Mac OS X Mountain Lion :
iconv -l | grep MAC
UTF-8-MAC UTF8-MAC
MAC MACINTOSH MACROMAN CSMACINTOSH
...

Je soupçonne que c'est juste un nom donné à de l'UTF-8 encodant de l'Unicode
sous forme canonique décomposée, parce que apple ne pouvait pas décemment
utiliser la forme canonique composée comme tout le monde, ça aurait rendu
l'interopérabilité trop facile.



c'est pas du tout ça, le décomposé est un truc sioux, mais emmerdant il
est vrai, qui permet de faire un sort alphabétique + rapidement.

>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)


rsync est un outil Unix, s'il travaille avec des filesystems décents (pas
FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.

Accessoirement :

# 3.276 Portable Filename Character Set



ouais, d'accord, mais, ce n'est pas moi qui ai choisi ces filenames et
quand même cette politique, même si je la pratique en enlevant tous les
signes diacritiques, dans les filenames, cette politique est pou le
moins viellotte, les chinois ont maintenant des FDQN en chinois, c'est
quand même plus respectueux de la diversité...
Une Bévue
Le #24973902
Le 18/11/12 21:46, Erwan David a écrit :
rsync est un outil Unix, s'il travaille avec des filesystems décents (pas
>FAT ou NTFS), il travaille avec des octets et se fiche de l'encodage.
>


Certes, mais l'option de rsync sers à ce que le nom de fichier soit
correctement converti selon les FS de départ et d'arrivée.



Non, c'est faux d'ailleurs rsync ne se fiche pas de l'encodage, (voir la
FAQ) car il est incapable de faire une sync entre deux fs à encodage
différent sans iconv.
Nicolas George
Le #24975282
Une Bévue , dans le message écrit :
You can avoid a charset problem by passing an appropriate --iconv option
to rsync that tells it what character-set the source files are, and what
character-set the destination files get stored in. For instance, the
above Mac OS X problem would be dealt with by using
--iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac
OS X iconv in which all characters are decomposed).



Il n'y a pas de notion d'encodage des noms de fichiers sous Unix, les noms
de fichiers sont des suites d'octets, point.

et sur Mac OS X Mountain Lion :



macos est une caricature d'Unix, il ne faut pas le prendre comme référence.

c'est pas du tout ça, le décomposé est un truc sioux, mais emmerdant il
est vrai, qui permet de faire un sort alphabétique + rapidement.



Ça, c'est ce qu'on dit aux macounets un peu moins endoctrinés que les autres
qui sont capables de se rendre compte du problème, mais pas de comprendre
que c'est du pipo.

ouais, d'accord, mais, ce n'est pas moi qui ai choisi ces filenames et



Ils sont sur ton ordinateur, non ?

quand même cette politique, même si je la pratique en enlevant tous les
signes diacritiques, dans les filenames, cette politique est pou le
moins viellotte, les chinois ont maintenant des FDQN en chinois, c'est
quand même plus respectueux de la diversité...



Les Chinois font ce qu'ils veulent, s'ils veulent des ennuis d'encodage
c'est leur problème.
Une Bévue
Le #24975332
Le 19/11/2012 18:01, Nicolas George a écrit :
Ils sont sur ton ordinateur, non ?


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.

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.

et ça ça me fait singulièrement chier, ya pas d'autre mot parce que je
ne peux pas faire du rsync comme je veux.

rsync, avec l'option iconv, s'en dépatouille bien côté mac mais côté
linux, ça mouline dans la choucroute, enfin j'ai des doublons et des
trucs qui sont téléchargés plusieurs fois.
Erwan David
Le #24975322
Nicolas George
Une Bévue , dans le message écrit :
You can avoid a charset problem by passing an appropriate --iconv option
to rsync that tells it what character-set the source files are, and what
character-set the destination files get stored in. For instance, the
above Mac OS X problem would be dealt with by using
--iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac
OS X iconv in which all characters are decomposed).



Il n'y a pas de notion d'encodage des noms de fichiers sous Unix, les noms
de fichiers sont des suites d'octets, point.



Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?

Non ce n'est pas une suite d'octest, c'est une suite de caractères, idem
pour un open.

--
Les simplifications c'est trop compliqué
Une Bévue
Le #24975312
Le 19/11/2012 18:27, Erwan David a écrit :
Et quand tu f ais un ls, ce qu'il affiche c'est quoi ?



Côté xubuntu :
$ ls Pra*
Pražák Quartet - Arnold Schönberg

Non ce n'est pas une suite d'octest, c'est une suite de caractères, idem
pour un open.



ben oui il y a des découpages...
jp willm
Le #24975672
Hello,

Le 19/11/2012 18:22, Une Bévue 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.



Un fichier "mal" nommé peut tôt ou tard poser problème.


Je mouline le tout avec pyrenamer ou gprename pour supprimer les
accents, les espaces et pour tout mettre en minuscule (extensions
comprises, car sous gtk les photos sont toujours importées avec des
extensions en majuscule).

Depuis, je suis tranquille.


--
jp willm
http://perso.orange.fr/willms/index.html
Une Bévue
Le #24975702
Le 19/11/2012 19:29, jp willm a écrit :

Depuis, je suis tranquille.




c'est sûr, mais c'est du boulot...
Publicité
Poster une réponse
Anonyme