lire un fichier sur tout les OS

[cronos6]

Bonsoir,

Je rencontre un problème assez récurent qui est la lecture d'un fichier sur dfférent OS.

Soit les espaces sont géré bizarrement, soit il y a des problèmes d'accents.

Je ne sais plus quoi faire, je suis perdu avec les différents types d'encodage. Puis il y a un collègue qui me parlait d'une commande sous linux qu'il fallait appliquer au fichier avant de le passer sous windows.

Bref, faire transitier un fichier sous Windows/Linux/Macos, c'est pas facile facile


Je suppose qu'il y a des précautions à prendre pour pouvoir lire un fichier partout ; et ce que vous pourriez m'aider :rose:

 

[bompi]

Pour qu'un fichier soit lu sans encombre sur ces trois environnements, il suffit qu'il ne contienne que des caractères alphanumériques non accentués (a-z, A-Z, 0-9) et les signes de ponctuation et mathématiques usuels. Dans ce cas, on reste dans la codification ASCII (sur 7 bits) et non ISO (8 bits).
Dès que l'on utilise un caractère latin accentué, il va falloir opter pour une table de codage. Dans nos contrées francophones, c'est normalement le ISO-8859-1 (et pour avoir l'euro : ISO-8859-15). Mais pour les héllènophones, les russophones, et tous les autres -ophones, il faut un autre codage ...
Par ailleurs, Linux et Mac OS X partagent, pour les fichiers de type texte (pas de caractère de contrôle en-dehors des fins de lignes), le même type de terminaison de ligne : le retour chariot (carriage return, code hexadécimal 0x0a, code usuel sous Unix : '\n').
Mais Windows utilise le retour chariot ET le passage à la ligne suivante (CRLF ou carriage return / Line Feed, codes 0x0a et 0x0d).
C'est pour cela qu'un fichier texte de Unix (Linux, Mac OS X et autres) ne fait qu'une seule ligne dans un éditeur de texte médiocre sous Windows.
La plupart des éditeurs de texte disponibles sous Linux et Mac OS X permettent de lire indifféremment tous ces fichiers texte. Sous Windows, il faut choisir un bon éditeur aussi (genre UltraEdit par exemple).

Pour ta gouverne : sous Mac OS X on essaye de développer le codages "universels" UTF-8 et UTF-16 qui permettent de coder TOUS les caractères dans TOUS les langages (pour le -16 ; pour le -8 il y a seulement PRESQUE tout). Mais il est difficile de faire changer les choses dans ce domaine donc on n'en est qu'au balbutiement du codage universel (c'est du moins mon impression).

 

[cronos6]

Merci beaucoup pour ce petit cours

donc si j'ai bien compris, pour éviter tout problème, il faut tjrs

- enregistrer son documents en utf8
- fixer l'encodage de l'editeur de texte en utf8
- pour l'editeur de texte, joueur sur l'encodage des lignes en fonction de l'os (CRLF pour windows ; LF pour Unix ; CR pour mac)


est ce bien cela? :rose:

 

[bompi]

Je pense (mais je n'ai jamais vérifié) que, une fois en UTF-8, tu n'as plus à te soucier des fins de ligne. Bonne remarque : je vais voir demain au bureau.

 

[cronos6]

Aujourd'hui j'ai effectué des tests sur les trois OS et tout est passé (accent, saut de lignes) sans problèmes.
Comme tu le disais, l'editeur de texte s'occupe de tout.
La seul chose à s'assurer, c'est de placer l'editeur de texte en "utf8" quand c'est possible (notamment pour subethaedit dans les préférences). Et d'enregistrer son documents en "utf8". Après il devient lisible sur tout les trois OS cités. Sans oublier d'utiliser un editeur graphique correcte, par exemple :

- notepad++ pour windows
- gedit pour linux
- subethaedit pour mac os (seul reproche, il ne gère pas les onglets, donc pour 10 documents, ça fait 10 fenetres )


Ca fait déjà un problème de moins.
Il me reste plus qu'a tester ces consignes sur les bases de données de type "mysql" (création des tables en utf8 et exportation en utf8) et je n'aurais plus à me soucier des accentuations.


En tout cas merci pour les explications sur l'encodage