NFS et conversion UTF-8 / UTF-8-MAC, Je deviens fou...

Le
googleg
Bonjour à tous,
J'ai un petit problème avec la gestion des noms de fichiers dès lors
qu'ils contiennent des accents.

J'ai un serveur Linux (rPath) avec un filesystem réseau que je peux
accéder aussi bien en NFS qu'en SMB. Ce partage est bien sûr accédé
par des PC Windows (en SMB) comme par mon Mac (OS X 10.4) en NFS (pour
des questions de performances, le problème reste le même si j'accède
en SMB).

- Si un fichier avec un nom contenant des accents est créé depuis un
Windows le Mac ne pourra pas l'ouvrir (mais il pourra le voir),
- L'inverse ne pose pas de problème.
- Pour pouvoir accéder au fichier avec le Mac il me faut changer le
nom du fichier, virer l'accent, et éventuellement le remettre à
l'identique, mais depuis le Mac.

Après quelques recherches je trouve rapidement la cause de ce problème
mais malheureusement je n'ai pas pu trouver de solution : le Mac
utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC
Windows (et il semblerait la vaste majorité des systèmes) utilisent
une version différente de l'encodage UTF-8. Si les PC (et le linux)
semblent "flexibles" dans leur gestion des noms, reconnaissant à la
volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semb=
le
complètement rigide

J'ai d'abord cherché à changer les choses côté serveur, par exemple=
en
utilisant le Unix-Charset UTF-8-MAC sur le serveur Samba côté linux
mais malheureusement cet encodage est inconnu sur mon serveur (pas
présent dans le iconv -l). De plus, comme le "fautif" est finalement
le Mac je pense qu'il me faut plutôt chercher de ce côté.

La solution consistant à changer tous les noms sur le partage n'est
pas valable car il faudrait le faire à chaque fois qu'un fichier
contenant un accent est créé par un PC, ce n'est pas jouable.

J'ai essayé de monter le partage NFS sur le mac en passant l'option
iocharset=utf-8 mais ça ne donne rien

Le problème est connu et en cherchant je peux trouver de nombreux
témoignages sur le net (y compris sur ce groupe), mais je n'ai vu
aucune solution.

Est-ce que quelqu'un ici peut m'aider ?

D'avance merci.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #18005031
À (at) Fri, 28 Nov 2008 14:44:42 -0800 (PST),
écrivait (wrote):
Bonjour à tous,
J'ai un petit problème avec la gestion des noms de fichiers dès lors
qu'ils contiennent des accents.

J'ai un serveur Linux (rPath) avec un filesystem réseau que je peux
accéder aussi bien en NFS qu'en SMB. Ce partage est bien sûr accédé
par des PC Windows (en SMB) comme par mon Mac (OS X 10.4) en NFS (pour
des questions de performances, le problème reste le même si j'accède
en SMB).

- Si un fichier avec un nom contenant des accents est créé depuis un
Windows le Mac ne pourra pas l'ouvrir (mais il pourra le voir),
- L'inverse ne pose pas de problème.
- Pour pouvoir accéder au fichier avec le Mac il me faut changer le
nom du fichier, virer l'accent, et éventuellement le remettre à
l'identique, mais depuis le Mac.



Oui. On a le même problème avec le montage en lecture/écriture des
partition NTFS via ntfs-3g.

Après quelques recherches je trouve rapidement la cause de ce problème
mais malheureusement je n'ai pas pu trouver de solution : le Mac
utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC
Windows (et il semblerait la vaste majorité des systèmes) utilisent
une version différente de l'encodage UTF-8. Si les PC (et le linux)
semblent "flexibles" dans leur gestion des noms, reconnaissant à la
volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semble
complètement rigide...



C'est bien la bonne description du problème.

À noter tout de même qu'en passant par la ligne de commande, il n'y a
pas de problème : on peut éditer, modifier, copier, renommer tous les
fichiers comme on le veut. Le problème est donc dans la sur-couche
Apple et pas dans le noyau Darwin.

Est-ce que quelqu'un ici peut m'aider ?



La seule solution est une correction par Apple !

--
Paul Gaborit -
blanc
Le #18006561

Est-ce que quelqu'un ici peut m'aider ?



Tu as, je pense, des choses intéressantes qui ont été dites ici même :
<http://groups.google.com/group/fr.comp.os.mac-os.x/search?group=fr.comp
.os.mac-os.x&q=leopard+nfs&qt_g=Rechercher+dans+ce+groupe>

<http://groups.google.com/group/fr.comp.os.mac-os.x/search?group=fr.comp
.os.mac-os.x&q=utf-8+NFC%2C+NFD%2C+NFKD+et+NFKC&qt_g=Rechercher+dans+ce+
groupe>

avec référence à cette page

Autres pages intéressantes chez Apple :

et sur wikipedia (English) :

Ensuite. Pourquoi Apple n'est pas capable de lire les formes utilisées
sous win ou linux, je ne sais pas. Et ne sais pas non plus comment
contourner ce pb.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
googleg
Le #18008391
On 30 nov, 16:16, Paul Gaborit
Oui. On a le même problème avec le montage en lecture/écriture des
partition NTFS via ntfs-3g.


[...]
Le problème est donc dans la sur-couche
Apple et pas dans le noyau Darwin.


[...]
La seule solution est une correction par Apple !



J'avais espéré qu'il y ait une autre solution, les messages étant dan s
l'ensemble assez vieux, je me disais que certains avaient trouvé. A
noter que rsync comprend une option --iconv bien utile pour ce
problème... Ne serait-il pas envisageable de compiler des outils qui
vont bien ?
blanc
Le #18009331
JiPaul
et sur wikipedia (English) :



Je me suis d'ailleurs lancé dans la traduction de ce texte, histoire de
mieux comprendre... :-)
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
blanc
Le #18009711
JiPaul
Je me suis d'ailleurs lancé dans la traduction de ce texte, histoire de
mieux comprendre... :-)



Et j'ai trouvé, en français, le texte suivant, qui a l'air beaucoup plus
précis :
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
blanc
Le #18016001

Après quelques recherches je trouve rapidement la cause de ce problème
mais malheureusement je n'ai pas pu trouver de solution : le Mac
utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC
Windows (et il semblerait la vaste majorité des systèmes) utilisent
une version différente de l'encodage UTF-8. Si les PC (et le linux)
semblent "flexibles" dans leur gestion des noms, reconnaissant à la
volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semble
complètement rigide...



Après avoir lu en grande partie ce texte :

et traduit celui de Wikipedia :

je me permet de reformuler ta présentation du problème :
Il n'y a qu'un bien qu'un seul UTF-8 (manière de coder l'Unicode par
multi-octets) mais il y a plusieurs manières de représenter un même
caractère accentué dans l'Unicode :
- soit sous forme composée. Exemple : ñ
- soit sous forme décomposée. Exemple : n + ~

Ceci pour des raisons de compatibilités avec les autres systèmes de
codages que Unicode.
Pour permettre des comparaisons, tris, recherches, il existe quatre
formes normales. Peu importe sous quelle forme (composée ou décomposée)
sont stockés les noms de fichiers. Normalement le Mac (ou plutôt NFS
dans Mac) devrait commencer par traduire dans la forme normale qu'il
utilise. Apparemment il ne le fait pas (ou il le fait mal) alors que win
ou linux le font bien (c'est en cela qu'ils sont plus "flexibles"). Donc
amha c'est bien un problème que devrait corriger Apple (ou plus
précisément ceux qui ont conçu l'interface NFS chez Apple), et il
faudrait peut-être qu'on fasse une remontée de bug. :-/

--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
googleg
Le #18018681
On 1 déc, 18:05, (JiPaul) wrote:
Donc
amha c'est bien un problème que devrait corriger Apple (ou plus
précisément ceux qui ont conçu l'interface NFS chez Apple), et il
faudrait peut-être qu'on fasse une remontée de bug. :-/



Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir
comment ouvrir un rapport de bug sur le site apple...
blanc
Le #18019581

Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir
comment ouvrir un rapport de bug sur le site apple...



http://www.apple.com/feedback/
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Eric Levenez
Le #18019571
Le 01/12/08 23:35, dans « JiPaul »

Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir
comment ouvrir un rapport de bug sur le site apple...



http://www.apple.com/feedback/



Le mieux étant être gratuit).

Rappel : plus il y a de bug reports pour un bug donné, plus celui-ci a des
chances d'être corrigé, et il ne faut pas croire que "les autres" feront le
bug report à notre place.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.
googleg
Le #18022961
On 1 déc, 23:44, Eric Levenez
Le mieux étant être gratuit).



Bon, je viens de m'inscrire et de faire mon rapport de bug !

J'ai un peu l'impression de pleurer dans un violon mais sait-on
jamais... Je suis encore jeune, peut-être que le bug sera corrigé
avant ma mort.
Publicité
Poster une réponse
Anonyme