Encodage de fichier Java, transmission Windows vers Unix

Version imprimable

1) Pour bien encoder mon fichier en ascii, est-ce le code suivant n'est pas suffisant? (je reste en utf8 sans bom)
comment préciser de façon systématique et sûre?
Code:

1 2 3 4 5 6 7 File fichier = new File("toto.txt"); System.setProperty("file.encoding","US-ASCII"); // fichier ouvert en mode append try { final BufferedWriter out = new BufferedWriter(new FileWriter( fichier));
2) autre question, je génère un fichier qui est ensuite transmis dans un système unix,
est-ce que mon code ci-dessous est adapté?
Code:

1 2 out.write(chaineEnregistrementTraite); out.newLine();
Quels sont les risques? Avez-vous des solutions?

:calim2::aie::mouarf:

02/10/2015, 15h47
thelvin
Citation:

Envoyé par batou22003

1) Pour bien encoder mon fichier en ascii, est-ce le code suivant n'est pas suffisant? (je reste en utf8 sans bom)
comment préciser de façon systématique et sûre?
Code:

1 2 3 4 Path path = Paths.get("toto.txt"); try(Writer writer = Files.newBufferedWriter(path, StandardCharsets.US_ASCII)) { }
Ceci étant dit, quand un fichier est en ASCII, il est identique au même fichier en utf-8 sans bom, forcément. C'est un peu ce qui a fait le succès d'utf-8.

Citation:

Envoyé par batou22003

2) autre question, je génère un fichier qui est ensuite transmis dans un système unix,
est-ce que mon code ci-dessous est adapté?

Comme le dit un grand maître Pandaren,

... Ce n'est peut-être pas... La bonne question.

Le code adapté, est celui qui produit le fichier adapté. Le fichier est adapté s'il est tel qu'il doit être pour marcher.
Un fichier se fiche complètement de s'il est sur Windows, Unix ou Zerfslt (l'OS multiversel zorblaxien.) Il se fiche complètement de s'il est transféré de l'un à l'autre.

Ce que tu dois faire, c'est regarder à quoi doit ressembler ton fichier pour marcher.
Et ton code Java doit faire en sorte que ce fichier soit tel qu'il doit être.
04/10/2015, 13h07
tchize_

Et pour info, ceci n'a aucun effet il me semble:

Code:

System.setProperty("file.encoding","US-ASCII");

Cette propriété n'est lue qu'au démarrage de la JVM, plus après.
05/10/2015, 09h03
batou22003

encodage

Merci pour vos réponses.

Je vais tester ce code. Je me demande également si je ne risque pas d'avoir des problèmes d'accents avec l'ASCII. Je m'excuse encore de mes questions, je ne m'y connais pas beaucoup en encodage. Et en utf8 sans bom, les accents passent?
05/10/2015, 09h27
adiGuba

Citation:

Envoyé par thelvin

Le code adapté, est celui qui produit le fichier adapté. Le fichier est adapté s'il est tel qu'il doit être pour marcher.
Un fichier se fiche complètement de s'il est sur Windows, Unix ou Zerfslt (l'OS multiversel zorblaxien.) Il se fiche complètement de s'il est transféré de l'un à l'autre.

En plus de l'encodage, il y a quand même une différence sur les fins de ligne, représenté par "\n" ou "\r\n" selon les systèmes.

La méthode newLine() du BufferedReader écrit la fin de ligne du système hôte...

Citation:

Envoyé par batou22003

Je vais tester ce code. Je me demande également si je ne risque pas d'avoir des problèmes d'accents avec l'ASCII. Je m'excuse encore de mes questions, je ne m'y connais pas beaucoup en encodage. Et en utf8 sans bom, les accents passent?

Heu... Il n'y a pas d'accents en ASCII !!!

Sinon l'UTF-8 te permet de représenter tous les caractères.
Le BOM ne rentre pas en compte (c'est juste un marqueur permettant de faciliter la reconnaissance de l'encodage du fichier).

a++
05/10/2015, 10h12
batou22003

encodage

L'ascii ne supporte pas les accents.

Peut -etre que je m'inquiète pour rien, le client pour qui je développe le fichier utilisé par leur programme a écrit plusieurs fois sur ses documents encodage ASCII .
J'essaie d'anticiper sur les problèmes d'encodage pouvant intervenir , dans le cas où il me confirme que l'encodage est uniquement en ASCII.
Je lui demande également de confirmer si l'encodage utilisé par son programme supporte les accents.
Et si il n'est pas contraint par son environnement pour la lecture des passages à la ligne d'un fichier généré par Windows. En effet, je ne sais pas comment ils vont lire notre fichier.

Merci encore de votre aide.
:P:lol:
05/10/2015, 10h21
tchize_

en très gros en ASCII, tu aura les lettres, les chiffres, la ponctuation, les différentes types de parenthèses.

https://en.wikipedia.org/wiki/ASCII#...ble_code_chart

l'ascii c'est du 7bits.

Vérifie quand même que ton client raconte pas de conneries. Beaucoup de gens confondent ascii et "ascii étendu". Le premier est un encodage, le deuxième un miriades d'encodages différents suivant le pays et l'os. Toute la série des ISO-8859-XX rentrent dans la catégories des ascii étendus. Toute la série des code page windows aussi.
05/10/2015, 11h05
batou22003

encodage
le code donné ne fonctionne pas en 1.6, c'est du 1.7
Code:

1 2 3 4 Path path = Paths.get("toto.txt"); try(Writer writer = Files.newBufferedWriter(path, StandardCharsets.US_ASCII)) { }
J'ai un autre contructeur dans lequel je peux mettre de l'encodage mais c'est plus du java.io :

Code:

com.ibm.ws.webservices.utils.BufferedWriter(out, os, enc)

Que me conseillez vous d' utiliser pour préciser l'encodage pour un fichier texte simple à générer? J'y écris des chaine puis je fais des retour à la ligne?

:):)
05/10/2015, 11h23
tchize_
Code:

1 2 3 java.io.OutputStream os = ... java.io.Writer writer = new java.io.OutputStreamWriter(os,"US-ASCII"); java.io.BufferedWriter bw = new java.io.BufferedWriter(writer);
En n'oubliant pas les 3 try, finally pour tout le nettoyage.
Aussi, tu devrais éviter une java aussi vieille que 1.6 pour de nouveaux projets.
05/10/2015, 12h03
batou22003

encodage

Comment j'initialise le

Code:

java.io.OutputStream os = ...

pour qu'il me crée un fichier nommé "toto.txt"

avant j'avais

Code:

File fichier = new File("toto.txt");
05/10/2015, 12h05
tchize_

FileOutputStream

encodage

j'ai eu l'info complète, c'est du iso latin 15.

Du coup, j'ai écris le code suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 File fichier = new File("monfichier.txt"); BufferedWriter out=null; try { out = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(fichier), "ISO8859_15")); } catch (UnsupportedEncodingException e1) { System.out.println("format non supporté"); //e1.printStackTrace(); } catch (FileNotFoundException e1) { System.out.println("fichier non trouvé"); //e1.printStackTrace(); }
Quand j'ouvre le fichier sous Notepad++, il me dit que c'est du ANSI, mais bon.
A prioris le code ISO8859_15 semble etre le bon. Il semble que l'exception, unsupportedEncodingException soit jamais détectée. J'ai
mis des codes bidons, et ca plante uniquement à l'écriture.

Reste la question du retour à la ligne. Je génère des fichiers qui seront lus sous Unix.
Pour les retour à la ligne que dois-je mettre ?

actuellement je fais un out.newLine();

Dois-je faire un truc du genre out.write("\n") pour être bien?

05/10/2015, 17h54
thelvin

Citation:

Envoyé par batou22003

Quand j'ouvre le fichier sous Notepad++, il me dit que c'est du ANSI, mais bon.

Il n'a aucun moyen de faire la différence, en fait. Ça ne concerne que des caractères comme € ou œ, tu les auras pas souvent.

Citation:

Envoyé par batou22003

A priori le code ISO8859_15 semble être le bon.

Il fera bien l'affaire, oui.

Citation:

Envoyé par batou22003

Reste la question du retour à la ligne. Je génère des fichiers qui seront lus sous Unix.
Pour les retour à la ligne que dois-je mettre ?

actuellement je fais un out.newLine();

Dois-je faire un truc du genre out.write("\n") pour être bien?

Comme l'a dit adiGuba, out.newLine() se comporte différemment en fonction du système sur lequel ton programme Java tourne.
Si le fichier à créer est pour Unix et ça ne dépend de rien du tout, alors elle n'est pas adaptée.
Il faut bien out.write("\n") . C'est en général l'usage pour les fichiers spécifiques Unix. Mais pour tout ce qui est fichiers modernes, cette différence de systèmes est obsolète depuis longtemps. La bonne c'est celle du fichier, ça n'a rien à voir avec le système. Et pour un fichier CSV par exemple, on se fiche royalement de s'il va être lu sur du Unix. Ce qui compte c'est ce que veut le programme qui va le lire.
05/10/2015, 18h38
tchize_

Je suis étonné que tu n'aie pas un UnsupportedEncodingException lancé, le nom correct est normalement "ISO-8859-15"
05/10/2015, 19h43
thelvin

Java accepte les alias, et ceci en est un.
06/10/2015, 10h17
batou22003

Citation:

Envoyé par tchize_

Je suis étonné que tu n'aie pas un UnsupportedEncodingException lancé, le nom correct est normalement "ISO-8859-15"

Oui, mais j'utilise un constructeur OutputStreamWriter() de java.io et pas java.nio.
Le nom d'encodage est ISO-8859-15 pour nio et ISO8859_15 pour java.io.OutputStreamWriter
06/10/2015, 11h43
thelvin

Citation:

Envoyé par batou22003

Oui, mais j'utilise un constructeur OutputStreamWriter() de java.io et pas java.nio.
Le nom d'encodage est ISO-8859-15 pour nio et ISO8859_15 pour java.io.OutputStreamWriter

Non, ils obéissent aux mêmes règles.
ISO8859_15 est simplement l'un des nombreux alias de ISO-8859-15. Demander l'un ou l'autre fournira la même chose.

merci. Effectivement c'est un alias, j'arrive à passer les 2 :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
File fichier = new File("toto.txt");
		OutputStream monOut = null;
		try {
			monOut = new FileOutputStream(fichier);
		} catch (FileNotFoundException e2) {
			System.out.println("Impossible de créer le fichier");
		}
 
	//ISO8859_15 ou ISO-8859-15
		BufferedWriter out=null;
		try {
				out = new BufferedWriter(new OutputStreamWriter(monOut, "ISO8859_15"));
		} catch (UnsupportedEncodingException e1) {
			System.out.println("Format non supporté");
			//e1.printStackTrace();
		} 
                ...
               try{
		out.write("\n");
                out.close();
               } ...

Le fichier est bien généré, merci de votre aide. Je passe le sujet en résolu.

:lol:

06/10/2015, 18h03
tchize_

N'oublie quand même pas de gérer correctement tes fermetures de flux hein :)
07/10/2015, 09h54
adiGuba

Citation:

Envoyé par tchize_

N'oublie quand même pas de gérer correctement tes fermetures de flux hein :)

Et virer tous ces try/catch inutile et incorrect.

Si tu veux traiter l'exception il faut utiliser un seul try/catch qui englobe le tout...

a++