montage NFS, encodage des noms de fichiers, et rsync
17 réponses
pehache
(léger xpost sans fu2)
Bonjour,
Sur un Mac sous 10.12 j'ai un montage NFS d'un dossier partagé sur un
NAS Synology (qui tourne sous un Linux). Pour ça j'utilise automount
avec une entrée dans le fichier /etc/auto_nfs :
---------------------------
Programs -fstype=nfs,noatime,rw,nfc nfs://synonas:/volume1/Programs
---------------------------
D'après le man de mount_nfs, l'option "nfc" sert à convertir l'encodage
des caractères des noms des fichiers : macOS et Linux utilisent tous
deux UTF8, mais il y a deux variantes qui notamment encodent
différemment les caractères accentués: NFD (macOS) et NFC (Linux). Bien...
Maintenant je fais un rsync sur le Mac pour synchroniser des fichiers du
serveur vers le Mac. Quelque chose comme :
---------------------------
$ rsync -av --delete /mnt/nfs/Programs/SOURCE/ ./DESTINATION
---------------------------
Ca marche, sauf que les fichiers comportant des caractères accentués
dans les noms sont systématiquement recopiés, même quand ils n'ont pas
été modifiés entre deux rsync. Les fichiers dont les noms ne comportent
pas de caractères spéciaux ne sont eux recopiés que s'ils ont été
modifiés, comme prévu.
En cherchant un peu je vois que l'option --iconv de rsync permet de
gérer les encodages différents :
---------------------------
--iconv=LOCAL,REMOTE
---------------------------
LOCAL étant l'encodage sur la machine où rsync tourne, REMOTE étant
l'encodage sur le serveur distant.
Déjà, la version de rsync par défaut sous macOS 10.12 est trop vieille
et n'a pas l'option --iconv, j'ai donc installé le rsync fourni par
MacPorts, plus récent.
Depuis un Mac vers un serveur Linux, il est conseillé un peu partout sur
le web de mettre :
---------------------------
--iconv=utf-8-mac,utf-8
---------------------------
utf-8 correspond à la variante NFC d'UFT8, utf-8-mac à la variante NFD
Sauf que dans mon cas ça ne change rien, les fichiers avec accents sont
toujours recopiés à chaque fois. En tâtonnant je trouve que ce qui
marche c'est l'un des deux :
---------------------------
--iconv=utf-8,utf-8-mac
--iconv=utf-8-mac,utf-8-mac
---------------------------
Problème résolu, les fichiers ne sont plus recopiés pour rien,
MAIS JE NE COMPRENDS RIEN DE CE QUI SE PASSE !
1) Déjà, pourquoi y a-t-il besoin du --iconv, alors que l'option "nfc"
du montage NFS est justement là pour faire les conversions nécessaires
et présenter à macOS les fichiers du serveur comme s'il étaient en UT8-NFD ?
2) la solution --iconv=utf-8,utf-8-mac dit que l'encodage local est du
UTF8-NFC, alors que la réalité c'est du UTF8-NFD : une explication ?
3) la solution --iconv=utf-8-mac,utf-8-mac est censée ne rien convertir
en définitive... Donc pourquoi elle ne se comporte pas pareil que sans
--iconv du tout ??
Si quelqu'un veut bien m'éclairer...
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Tu as tout à fait raison ! Quand je passe de macOS à Windows 10 via Bootcamp, le changement est tel que j'abandonne toute idée d'apostasie. Il n'est même pas nécessaire de faire appel à l'Inquisition.
C'est le problème quand on n'est pas adaptable.
Le 03/05/2019 à 14:48, Patrick a écrit :
Tu as tout à fait raison ! Quand je passe de macOS à Windows 10 via
Bootcamp, le changement est tel que j'abandonne toute idée d'apostasie.
Il n'est même pas nécessaire de faire appel à l'Inquisition.
Tu as tout à fait raison ! Quand je passe de macOS à Windows 10 via Bootcamp, le changement est tel que j'abandonne toute idée d'apostasie. Il n'est même pas nécessaire de faire appel à l'Inquisition.
C'est le problème quand on n'est pas adaptable.
Sergio
Le 03/05/2019 à 14:04, pehache a écrit :
Le 03/05/2019 à 11:59, Sergio a écrit :
Le 03/05/2019 à 10:28, Nicolas George a écrit :
Ce qui ici se traduit par : si tu utilises autre chose que a-zA-Z0-9_.- dans tes noms de fichiers, tu cherches les coups.
Habitude des maqueux dès le début. Aussi des suites bureautiques (LibreOffice, MS-Office...) qui par défaut donne comme nom le début du texte.
Il faut dire que bon, tu donnes un nom qui veut dire quelque chose en français, naturellement tu utilises des accents si tu n'as pas connu l'informatique en ascii pur et dur...
Mais l'utilisateur moyen... Et comment qu'il font les chinois, arabes, hébreux et autres langues à alphabet non latin ? Certes à ma connaissance, les files systems "modernes" gèrent les noms de fichier en UTF-8 ou en Unicode, donc il ne devrait pas y avoir de défauts de transmission... -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 03/05/2019 à 14:04, pehache a écrit :
Le 03/05/2019 à 11:59, Sergio a écrit :
Le 03/05/2019 à 10:28, Nicolas George a écrit :
Ce qui ici se traduit par : si tu utilises autre chose que a-zA-Z0-9_.-
dans tes noms de fichiers, tu cherches les coups.
Habitude des maqueux dès le début.
Aussi des suites bureautiques (LibreOffice, MS-Office...) qui par défaut
donne comme nom le début du texte.
Il faut dire que bon, tu donnes un nom qui veut dire quelque chose en
français, naturellement tu utilises des accents si tu n'as pas connu
l'informatique en ascii pur et dur...
Mais l'utilisateur moyen...
Et comment qu'il font les chinois, arabes, hébreux et autres langues à alphabet non latin ?
Certes à ma connaissance, les files systems "modernes" gèrent les noms de fichier en UTF-8 ou en Unicode, donc il ne devrait pas y avoir de défauts de transmission...
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Ce qui ici se traduit par : si tu utilises autre chose que a-zA-Z0-9_.- dans tes noms de fichiers, tu cherches les coups.
Habitude des maqueux dès le début. Aussi des suites bureautiques (LibreOffice, MS-Office...) qui par défaut donne comme nom le début du texte.
Il faut dire que bon, tu donnes un nom qui veut dire quelque chose en français, naturellement tu utilises des accents si tu n'as pas connu l'informatique en ascii pur et dur...
Mais l'utilisateur moyen... Et comment qu'il font les chinois, arabes, hébreux et autres langues à alphabet non latin ? Certes à ma connaissance, les files systems "modernes" gèrent les noms de fichier en UTF-8 ou en Unicode, donc il ne devrait pas y avoir de défauts de transmission... -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
pehache
Le 03/05/2019 à 15:19, Sergio a écrit :
Le 03/05/2019 à 14:04, pehache a écrit :
Le 03/05/2019 à 11:59, Sergio a écrit :
Le 03/05/2019 à 10:28, Nicolas George a écrit :
Ce qui ici se traduit par : si tu utilises autre chose que a-zA-Z0-9_.- dans tes noms de fichiers, tu cherches les coups.
Habitude des maqueux dès le début. Aussi des suites bureautiques (LibreOffice, MS-Office...) qui par défaut donne comme nom le début du texte.
Il faut dire que bon, tu donnes un nom qui veut dire quelque chose en français, naturellement tu utilises des accents si tu n'as pas connu l'informatique en ascii pur et dur...
Mais l'utilisateur moyen...
Justement, c'est l'utilisateur moyen qui a tendance à ne pas se poser de question et à utiliser des accents dans les noms, puisque c'est possible de le faire.
Et comment qu'il font les chinois, arabes, hébreux et autres langues à alphabet non latin ?
Je ne sais pas quel est l'usage courant, mais au boulot j'ai reçu une fois des fichiers avec des noms en caractères non latins (chinois ? je ne sais plus, mais asiatiques en tous cas...). Le gars s'était trompé de fichiers.
Le 03/05/2019 à 15:19, Sergio a écrit :
Le 03/05/2019 à 14:04, pehache a écrit :
Le 03/05/2019 à 11:59, Sergio a écrit :
Le 03/05/2019 à 10:28, Nicolas George a écrit :
Ce qui ici se traduit par : si tu utilises autre chose que
a-zA-Z0-9_.-
dans tes noms de fichiers, tu cherches les coups.
Habitude des maqueux dès le début.
Aussi des suites bureautiques (LibreOffice, MS-Office...) qui par
défaut
donne comme nom le début du texte.
Il faut dire que bon, tu donnes un nom qui veut dire quelque chose en
français, naturellement tu utilises des accents si tu n'as pas connu
l'informatique en ascii pur et dur...
Mais l'utilisateur moyen...
Justement, c'est l'utilisateur moyen qui a tendance à ne pas se poser de
question et à utiliser des accents dans les noms, puisque c'est possible
de le faire.
Et comment qu'il font les chinois, arabes, hébreux et autres langues à
alphabet non latin ?
Je ne sais pas quel est l'usage courant, mais au boulot j'ai reçu une fois
des fichiers avec des noms en caractères non latins (chinois ? je ne sais
plus, mais asiatiques en tous cas...). Le gars s'était trompé de
fichiers.
Ce qui ici se traduit par : si tu utilises autre chose que a-zA-Z0-9_.- dans tes noms de fichiers, tu cherches les coups.
Habitude des maqueux dès le début. Aussi des suites bureautiques (LibreOffice, MS-Office...) qui par défaut donne comme nom le début du texte.
Il faut dire que bon, tu donnes un nom qui veut dire quelque chose en français, naturellement tu utilises des accents si tu n'as pas connu l'informatique en ascii pur et dur...
Mais l'utilisateur moyen...
Justement, c'est l'utilisateur moyen qui a tendance à ne pas se poser de question et à utiliser des accents dans les noms, puisque c'est possible de le faire.
Et comment qu'il font les chinois, arabes, hébreux et autres langues à alphabet non latin ?
Je ne sais pas quel est l'usage courant, mais au boulot j'ai reçu une fois des fichiers avec des noms en caractères non latins (chinois ? je ne sais plus, mais asiatiques en tous cas...). Le gars s'était trompé de fichiers.
jg
Le 02/05/2019 à 23:07, pehache a écrit :
(léger xpost sans fu2) Bonjour, Sur un Mac sous 10.12 j'ai un montage NFS d'un dossier partagé sur un NAS Synology (qui tourne sous un Linux). Pour ça j'utilise automount avec une entrée dans le fichier /etc/auto_nfs : --------------------------- Programs -fstype=nfs,noatime,rw,nfc nfs://synonas:/volume1/Programs --------------------------- D'après le man de mount_nfs, l'option "nfc" sert à convertir l'encodage des caractères des noms des fichiers : macOS et Linux utilisent tous deux UTF8, mais il y a deux variantes qui notamment encodent différemment les caractères accentués: NFD (macOS) et NFC (Linux). Bien... Maintenant je fais un rsync sur le Mac pour synchroniser des fichiers du serveur vers le Mac. Quelque chose comme : --------------------------- $ rsync -av --delete /mnt/nfs/Programs/SOURCE/ ./DESTINATION --------------------------- Ca marche, sauf que les fichiers comportant des caractères accentués dans les noms sont systématiquement recopiés, même quand ils n'ont pas été modifiés entre deux rsync. Les fichiers dont les noms ne comportent pas de caractères spéciaux ne sont eux recopiés que s'ils ont été modifiés, comme prévu. En cherchant un peu je vois que l'option --iconv de rsync permet de gérer les encodages différents : --------------------------- --iconv=LOCAL,REMOTE --------------------------- LOCAL étant l'encodage sur la machine où rsync tourne, REMOTE étant l'encodage sur le serveur distant. Déjà, la version de rsync par défaut sous macOS 10.12 est trop vieille et n'a pas l'option --iconv, j'ai donc installé le rsync fourni par MacPorts, plus récent. Depuis un Mac vers un serveur Linux, il est conseillé un peu partout sur le web de mettre : --------------------------- --iconv=utf-8-mac,utf-8 --------------------------- utf-8 correspond à la variante NFC d'UFT8, utf-8-mac à la variante NFD Sauf que dans mon cas ça ne change rien, les fichiers avec accents sont toujours recopiés à chaque fois. En tâtonnant je trouve que ce qui marche c'est l'un des deux : --------------------------- --iconv=utf-8,utf-8-mac --iconv=utf-8-mac,utf-8-mac --------------------------- Problème résolu, les fichiers ne sont plus recopiés pour rien, MAIS JE NE COMPRENDS RIEN DE CE QUI SE PASSE ! 1) Déjà, pourquoi y a-t-il besoin du --iconv, alors que l'option "nfc" du montage NFS est justement là pour faire les conversions nécessaires et présenter à macOS les fichiers du serveur comme s'il étaient en UT8-NFD ? 2) la solution --iconv=utf-8,utf-8-mac dit que l'encodage local est du UTF8-NFC, alors que la réalité c'est du UTF8-NFD : une explication ? 3) la solution --iconv=utf-8-mac,utf-8-mac est censée ne rien convertir en définitive... Donc pourquoi elle ne se comporte pas pareil que sans --iconv du tout ?? Si quelqu'un veut bien m'éclairer...
Ca va pas servir à grand chose ce que je vais écrire, sauf pour l'avenir... peut-être. Informaticien de formation (1973 !!) et de métier, l'une des premières choses que l'on m'a appris est de toujours utiliser des minuscules non accentuées dans les noms de fichiers... Pour justement éviter les problèmes Mac/Linux/Windows. Bon, c'est trop tard...
Le 02/05/2019 à 23:07, pehache a écrit :
(léger xpost sans fu2)
Bonjour,
Sur un Mac sous 10.12 j'ai un montage NFS d'un dossier partagé sur un
NAS Synology (qui tourne sous un Linux). Pour ça j'utilise automount
avec une entrée dans le fichier /etc/auto_nfs :
---------------------------
Programs -fstype=nfs,noatime,rw,nfc nfs://synonas:/volume1/Programs
---------------------------
D'après le man de mount_nfs, l'option "nfc" sert à convertir l'encodage
des caractères des noms des fichiers : macOS et Linux utilisent tous
deux UTF8, mais il y a deux variantes qui notamment encodent
différemment les caractères accentués: NFD (macOS) et NFC (Linux). Bien...
Maintenant je fais un rsync sur le Mac pour synchroniser des fichiers du
serveur vers le Mac. Quelque chose comme :
---------------------------
$ rsync -av --delete /mnt/nfs/Programs/SOURCE/ ./DESTINATION
---------------------------
Ca marche, sauf que les fichiers comportant des caractères accentués
dans les noms sont systématiquement recopiés, même quand ils n'ont pas
été modifiés entre deux rsync. Les fichiers dont les noms ne comportent
pas de caractères spéciaux ne sont eux recopiés que s'ils ont été
modifiés, comme prévu.
En cherchant un peu je vois que l'option --iconv de rsync permet de
gérer les encodages différents :
---------------------------
--iconv=LOCAL,REMOTE
---------------------------
LOCAL étant l'encodage sur la machine où rsync tourne, REMOTE étant
l'encodage sur le serveur distant.
Déjà, la version de rsync par défaut sous macOS 10.12 est trop vieille
et n'a pas l'option --iconv, j'ai donc installé le rsync fourni par
MacPorts, plus récent.
Depuis un Mac vers un serveur Linux, il est conseillé un peu partout sur
le web de mettre :
---------------------------
--iconv=utf-8-mac,utf-8
---------------------------
utf-8 correspond à la variante NFC d'UFT8, utf-8-mac à la variante NFD
Sauf que dans mon cas ça ne change rien, les fichiers avec accents sont
toujours recopiés à chaque fois. En tâtonnant je trouve que ce qui
marche c'est l'un des deux :
---------------------------
--iconv=utf-8,utf-8-mac
--iconv=utf-8-mac,utf-8-mac
---------------------------
Problème résolu, les fichiers ne sont plus recopiés pour rien,
MAIS JE NE COMPRENDS RIEN DE CE QUI SE PASSE !
1) Déjà, pourquoi y a-t-il besoin du --iconv, alors que l'option "nfc"
du montage NFS est justement là pour faire les conversions nécessaires
et présenter à macOS les fichiers du serveur comme s'il étaient en
UT8-NFD ?
2) la solution --iconv=utf-8,utf-8-mac dit que l'encodage local est du
UTF8-NFC, alors que la réalité c'est du UTF8-NFD : une explication ?
3) la solution --iconv=utf-8-mac,utf-8-mac est censée ne rien convertir
en définitive... Donc pourquoi elle ne se comporte pas pareil que sans
--iconv du tout ??
Si quelqu'un veut bien m'éclairer...
Ca va pas servir à grand chose ce que je vais écrire, sauf pour
l'avenir... peut-être.
Informaticien de formation (1973 !!) et de métier, l'une des premières
choses que l'on m'a appris est de toujours utiliser des minuscules non
accentuées dans les noms de fichiers... Pour justement éviter les
problèmes Mac/Linux/Windows.
(léger xpost sans fu2) Bonjour, Sur un Mac sous 10.12 j'ai un montage NFS d'un dossier partagé sur un NAS Synology (qui tourne sous un Linux). Pour ça j'utilise automount avec une entrée dans le fichier /etc/auto_nfs : --------------------------- Programs -fstype=nfs,noatime,rw,nfc nfs://synonas:/volume1/Programs --------------------------- D'après le man de mount_nfs, l'option "nfc" sert à convertir l'encodage des caractères des noms des fichiers : macOS et Linux utilisent tous deux UTF8, mais il y a deux variantes qui notamment encodent différemment les caractères accentués: NFD (macOS) et NFC (Linux). Bien... Maintenant je fais un rsync sur le Mac pour synchroniser des fichiers du serveur vers le Mac. Quelque chose comme : --------------------------- $ rsync -av --delete /mnt/nfs/Programs/SOURCE/ ./DESTINATION --------------------------- Ca marche, sauf que les fichiers comportant des caractères accentués dans les noms sont systématiquement recopiés, même quand ils n'ont pas été modifiés entre deux rsync. Les fichiers dont les noms ne comportent pas de caractères spéciaux ne sont eux recopiés que s'ils ont été modifiés, comme prévu. En cherchant un peu je vois que l'option --iconv de rsync permet de gérer les encodages différents : --------------------------- --iconv=LOCAL,REMOTE --------------------------- LOCAL étant l'encodage sur la machine où rsync tourne, REMOTE étant l'encodage sur le serveur distant. Déjà, la version de rsync par défaut sous macOS 10.12 est trop vieille et n'a pas l'option --iconv, j'ai donc installé le rsync fourni par MacPorts, plus récent. Depuis un Mac vers un serveur Linux, il est conseillé un peu partout sur le web de mettre : --------------------------- --iconv=utf-8-mac,utf-8 --------------------------- utf-8 correspond à la variante NFC d'UFT8, utf-8-mac à la variante NFD Sauf que dans mon cas ça ne change rien, les fichiers avec accents sont toujours recopiés à chaque fois. En tâtonnant je trouve que ce qui marche c'est l'un des deux : --------------------------- --iconv=utf-8,utf-8-mac --iconv=utf-8-mac,utf-8-mac --------------------------- Problème résolu, les fichiers ne sont plus recopiés pour rien, MAIS JE NE COMPRENDS RIEN DE CE QUI SE PASSE ! 1) Déjà, pourquoi y a-t-il besoin du --iconv, alors que l'option "nfc" du montage NFS est justement là pour faire les conversions nécessaires et présenter à macOS les fichiers du serveur comme s'il étaient en UT8-NFD ? 2) la solution --iconv=utf-8,utf-8-mac dit que l'encodage local est du UTF8-NFC, alors que la réalité c'est du UTF8-NFD : une explication ? 3) la solution --iconv=utf-8-mac,utf-8-mac est censée ne rien convertir en définitive... Donc pourquoi elle ne se comporte pas pareil que sans --iconv du tout ?? Si quelqu'un veut bien m'éclairer...
Ca va pas servir à grand chose ce que je vais écrire, sauf pour l'avenir... peut-être. Informaticien de formation (1973 !!) et de métier, l'une des premières choses que l'on m'a appris est de toujours utiliser des minuscules non accentuées dans les noms de fichiers... Pour justement éviter les problèmes Mac/Linux/Windows. Bon, c'est trop tard...
Jean-Pierre Kuypers
In article (Dans l'article) <5ccca870$0$14384$, jg wrote (écrivait) :
Informaticien de formation (1973 !!) et de métier, l'une des premières choses que l'on m'a appris est de toujours utiliser des minuscules non accentuées dans les noms de fichiers... Pour justement éviter les problèmes Mac/Linux/Windows.
Et après les seuls 8 caractères, chiffres ou lettres majuscules, autorisés sur les "mainframes" IBM 360 ou autres du genre, on était tout fou devant ce vaste choix qui s'ouvrait à nous. -- Jean-Pierre Kuypers Veuillez accentuer les phrases dans leur con- texte avant de former sciemment.
In article (Dans l'article) <5ccca870$0$14384$426a74cc@news.free.fr>,
jg <jacques.guezenec@free.fr> wrote (écrivait) :
Informaticien de formation (1973 !!) et de métier, l'une des premières
choses que l'on m'a appris est de toujours utiliser des minuscules non
accentuées dans les noms de fichiers... Pour justement éviter les
problèmes Mac/Linux/Windows.
Et après les seuls 8 caractères, chiffres ou lettres majuscules,
autorisés sur les "mainframes" IBM 360 ou autres du genre, on était
tout fou devant ce vaste choix qui s'ouvrait à nous.
--
Jean-Pierre Kuypers
Veuillez accentuer les phrases dans leur con-
texte avant de former sciemment.
In article (Dans l'article) <5ccca870$0$14384$, jg wrote (écrivait) :
Informaticien de formation (1973 !!) et de métier, l'une des premières choses que l'on m'a appris est de toujours utiliser des minuscules non accentuées dans les noms de fichiers... Pour justement éviter les problèmes Mac/Linux/Windows.
Et après les seuls 8 caractères, chiffres ou lettres majuscules, autorisés sur les "mainframes" IBM 360 ou autres du genre, on était tout fou devant ce vaste choix qui s'ouvrait à nous. -- Jean-Pierre Kuypers Veuillez accentuer les phrases dans leur con- texte avant de former sciemment.
jg
Le 04/05/2019 à 20:28, Jean-Pierre Kuypers a écrit :
In article (Dans l'article) <5ccca870$0$14384$, jg wrote (écrivait) :
Informaticien de formation (1973 !!) et de métier, l'une des premières choses que l'on m'a appris est de toujours utiliser des minuscules non accentuées dans les noms de fichiers... Pour justement éviter les problèmes Mac/Linux/Windows.
Et après les seuls 8 caractères, chiffres ou lettres majuscules, autorisés sur les "mainframes" IBM 360 ou autres du genre, on était tout fou devant ce vaste choix qui s'ouvrait à nous.
Un connaisseur (j'ai connu cela aussi). :) Mais cela reste vrai pour les minuscules sans accents pour une raison simple, c'est que toutes les langues ne reconnaissent pas les accents (l'anglais par exemple) .
Le 04/05/2019 à 20:28, Jean-Pierre Kuypers a écrit :
In article (Dans l'article) <5ccca870$0$14384$426a74cc@news.free.fr>,
jg <jacques.guezenec@free.fr> wrote (écrivait) :
Informaticien de formation (1973 !!) et de métier, l'une des premières
choses que l'on m'a appris est de toujours utiliser des minuscules non
accentuées dans les noms de fichiers... Pour justement éviter les
problèmes Mac/Linux/Windows.
Et après les seuls 8 caractères, chiffres ou lettres majuscules,
autorisés sur les "mainframes" IBM 360 ou autres du genre, on était
tout fou devant ce vaste choix qui s'ouvrait à nous.
Un connaisseur (j'ai connu cela aussi). :)
Mais cela reste vrai pour les minuscules sans accents pour une raison
simple, c'est que toutes les langues ne reconnaissent pas les accents
(l'anglais par exemple) .
Le 04/05/2019 à 20:28, Jean-Pierre Kuypers a écrit :
In article (Dans l'article) <5ccca870$0$14384$, jg wrote (écrivait) :
Informaticien de formation (1973 !!) et de métier, l'une des premières choses que l'on m'a appris est de toujours utiliser des minuscules non accentuées dans les noms de fichiers... Pour justement éviter les problèmes Mac/Linux/Windows.
Et après les seuls 8 caractères, chiffres ou lettres majuscules, autorisés sur les "mainframes" IBM 360 ou autres du genre, on était tout fou devant ce vaste choix qui s'ouvrait à nous.
Un connaisseur (j'ai connu cela aussi). :) Mais cela reste vrai pour les minuscules sans accents pour une raison simple, c'est que toutes les langues ne reconnaissent pas les accents (l'anglais par exemple) .
truc
jg wrote:
Le 04/05/2019 à 20:28, Jean-Pierre Kuypers a écrit :
In article (Dans l'article) <5ccca870$0$14384$, jg wrote (écrivait) :
Informaticien de formation (1973 !!) et de métier, l'une des premières choses que l'on m'a appris est de toujours utiliser des minuscules non accentuées dans les noms de fichiers... Pour justement éviter les problèmes Mac/Linux/Windows.
Et après les seuls 8 caractères, chiffres ou lettres majuscules, autorisés sur les "mainframes" IBM 360 ou autres du genre, on était tout fou devant ce vaste choix qui s'ouvrait à nous.
Un connaisseur (j'ai connu cela aussi). :) Mais cela reste vrai pour les minuscules sans accents pour une raison simple, c'est que toutes les langues ne reconnaissent pas les accents (l'anglais par exemple) .
Sur certains sites web, vous ne pouvez inclure dans un libellé des lettres avec signes diacritiques. C'est ce qui se passe sur le Crédit Agricole quand je fais un libellé pour un virement. -- B. Graignic
jg <jacques.guezenec@free.fr> wrote:
Le 04/05/2019 à 20:28, Jean-Pierre Kuypers a écrit :
> In article (Dans l'article) <5ccca870$0$14384$426a74cc@news.free.fr>,
> jg <jacques.guezenec@free.fr> wrote (écrivait) :
>
>> Informaticien de formation (1973 !!) et de métier, l'une des premières
>> choses que l'on m'a appris est de toujours utiliser des minuscules non
>> accentuées dans les noms de fichiers... Pour justement éviter les
>> problèmes Mac/Linux/Windows.
>
> Et après les seuls 8 caractères, chiffres ou lettres majuscules,
> autorisés sur les "mainframes" IBM 360 ou autres du genre, on était
> tout fou devant ce vaste choix qui s'ouvrait à nous.
>
Un connaisseur (j'ai connu cela aussi). :)
Mais cela reste vrai pour les minuscules sans accents pour une raison
simple, c'est que toutes les langues ne reconnaissent pas les accents
(l'anglais par exemple) .
Sur certains sites web, vous ne pouvez inclure dans un libellé des
lettres avec signes diacritiques.
C'est ce qui se passe sur le Crédit Agricole quand je fais un libellé
pour un virement.
Le 04/05/2019 à 20:28, Jean-Pierre Kuypers a écrit :
In article (Dans l'article) <5ccca870$0$14384$, jg wrote (écrivait) :
Informaticien de formation (1973 !!) et de métier, l'une des premières choses que l'on m'a appris est de toujours utiliser des minuscules non accentuées dans les noms de fichiers... Pour justement éviter les problèmes Mac/Linux/Windows.
Et après les seuls 8 caractères, chiffres ou lettres majuscules, autorisés sur les "mainframes" IBM 360 ou autres du genre, on était tout fou devant ce vaste choix qui s'ouvrait à nous.
Un connaisseur (j'ai connu cela aussi). :) Mais cela reste vrai pour les minuscules sans accents pour une raison simple, c'est que toutes les langues ne reconnaissent pas les accents (l'anglais par exemple) .
Sur certains sites web, vous ne pouvez inclure dans un libellé des lettres avec signes diacritiques. C'est ce qui se passe sur le Crédit Agricole quand je fais un libellé pour un virement. -- B. Graignic
