Interopérabilité avec d'autres plates-formes

Les sections qui suivent décrivent certaines considérations pour les environnements multiplates-formes.

Considérations relatives au serveur NFS

Le protocole NFS version 4 (par défaut dans Oracle Solaris) utilise UTF-8 pour gérer les noms de fichier et d'autres chaînes. Par conséquent, dans la plupart des cas aucun ajustement lié aux jeux de caractères n'est nécessaire. Cependant, l'option charset peut servir si certains ou tous les clients utilisent un jeu de caractères spécifié.

Par exemple, pour partager le répertoire /export utilisant un jeu de caractères ISO8859-1, utilisez la commande suivante :

# share -o iso8859-1 /export

Pour partager un répertoire utilisant un jeu de caractères spécifique pour certaines machines, utilisez l'option charset=access_list :

# share -o iso-8859-1=isomachine.example.com,koi8-r=koimachine.example.com /export

Tous les noms de fichier et de chemin créés par les clients seront convertis au format UTF-8 sur le serveur.

Pour plus d'informations, reportez-vous à la page de manuel share_nfs(1M).

Considérations de système de fichiers

mount_pcfs(1M) ne prend pas en charge les pages de codes MS-DOS, mais les caractères non-ASCII sur les systèmes de fichiers FAT créés par MSDOS, ancienne version de MS Windows ou le pilote "msdos" de Linux, peuvent être illisibles. Les implémentations FAT ultérieures utilisent l'Unicode pour la représentation des caractères et sont totalement prises en charge sur Oracle Solaris par défaut, à la fois en lecture et en écriture.

Archives contenant les noms de fichiers non-ASCII

L'archivage de fichiers avec des noms comportant des caractères non-ASCII peut causer des problèmes car la prise en charge de ce type de caractères dans de nombreuses implémentations de formats d'archives particuliers varient énormément, même si cette situation tend à s'améliorer.

De récentes implémentations tar sur les systèmes UNIX et de type UNIX prennent en charge le format POSIX spécifié par POSIX.1-2001, et donc les noms de fichier non-ASCII sont gérés sans danger. Sur la plate-forme MS Windows un certain nombre d'utilitaires d'archivage stockent les noms de fichiers en utilisant les pages de codes actuelles, de sorte que les noms de fichiers extraits de telles archives peuvent être illisibles.

Dans ce cas, l'outil convmv(1) peut servir à les réparer, dans la mesure où la page de codes est connue :

$ convmv -f cp437 -t utf8 my_extracted_filename 

Dans les fichiers Zip, la spécification originale définit le codage des noms et des commentaires de fichiers sur IBM437. En 2007, PKWare a étendu la spécification afin d'autoriser l'UTF-8. Dans le même temps, différentes implémentations ZIP ont adopté l'utilisation de la page de codes actuelle comme codage des noms de fichier (généralement sur la plate-forme MS Windows).

Zip 3.0 d'Info-ZIP, utilisé dans Oracle Solaris 10 et Oracle Solaris 11, stocke les noms de fichiers au format UTF-8, donc si les utilitaires de compression et de décompression sont de cette version, le contenu des archives n'est pas corrompu.

Quand une archive zip utilisant un codage non UTF-8 pour stocker les noms de fichiers est extrait sur Oracle Solaris, les noms de fichiers peuvent être illisibles. Vous pouvez utiliser l'outil convmv(1) pour les réparer, quand la page de codes est connue :

    $ convmv -f cp437 -t utf8 my-unzipped-filename