Discussion :

[kij]

Bonjour,

J'ai un petit soucis pour écrire dans un fichier de rapport en JAVA.
Pour ce qui est d'écrire dans le fichier, je n'ai aucun pb, voici la partie de mon code pour que vous puissiez voir la partie "technique" :

La partie qui permet d'ouvrir le fichier en écriture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
// --- Ouverture du fichier :
output = new BufferedOutputStream(new FileOutputStream(getFilePath()) );
// --- Definition du buffer d'écriture
setWriter(new BufferedWriter(new OutputStreamWriter(output, "UTF-8")));

La partie qui permet d'écrire dans le fichier ouvert :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
// --- Write string in UTF-8 encoding
getWriter().write(theBuffer.toString());

Mon problème est le suivant : sur Window ca écrit impéccable en "mode texte" (UTF-8), par contre sous AIX, le fichier de rapport semble s'écrire en mode Binaire... et devient pour le coup illisible.

J'ai beau reprendre du code d'un autre projet qui fonctionne de la même manière et dont les fichiers de rapport sont lisible (fontionne également sous AIX), ca ne marche pas pour autant.
J'ai essayé avec un simple RandomAccessFile et sa méthode "writeBytes" -> mêmes résultats (lisible sous window mais pas sous AIX).

Je voulais savoir si quelqun avait déjà eu le même genre de problème et s'il pouvait éventuellement me donner un coup de pouce

Merci.

[kij]

Pour plus de compréhension, voici un exemple de ce que j'obtiens en affichant avec VI mon fichier de rapport (sous serveur AIX donc) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
^43?>^74^72?%^20^52^65^70?^72^74^2C^20+&<^20^58(<^20^66?^72_/^74^74^69>^67^20^72^65^70?^72^74^20^31^D^G^30^39^G^V^30^30^D^2
0^31^33^3A^30^35^2C^20>>>^0A^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^
E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E^E

Au lieu d'avoir (une fois transférer en mode binaire sous windows) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
Control Report, XXX XML formatting report 17/09/2007 10:40, nnn
------------------------------------------------------------------------
Input file :
	File origin : XXXXXXXX
	File name   : XXXXXXXXX
 
------------------------------------------------------------------------
Total number of :
	XXX document read    0
	XXX document written 0
 
------------------------------------------------------------------------
Probable error report :
	Fatal error label    : 
	Fatal error location :

[adiGuba]

Salut,

Pour plus de compréhension, voici un exemple de ce que j'obtiens en affichant avec VI mon fichier de rapport (sous serveur AIX donc)

Donc ton VI ne semble pas lire l'UTF-8 correctement...

Au lieu d'avoir (une fois transférer en mode binaire sous windows)

Et cela semble justifier ce que je pense : lorsque tu transfères en mode binaire tu transfères le fichier à l'identique !



Sinon cela n'a rien à voir mais pourquoi utiliser deux niveaux de bufferisation (BufferedOutputStream et BufferedWriter) ???
Un seul serait amplement suffisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
// --- Ouverture du fichier :
output = new FileOutputStream( getFilePath() );
// --- Definition du buffer d'écriture
setWriter(new BufferedWriter(new OutputStreamWriter(output, "UTF-8")));

a++

[kij]

Le double niveau de bufferisation n'est pas de moi mais d'un autre prog. J'ai simplement repris sans chercher à corriger le code car ce code fonctionne ailleurs. Ta remarque est certainement judicieuse Sans doute que le dev précédent avait prog ses fonctions avec un certains type et n'as pas voulu modifier tout son code ^^

Au départ j'ai fait avec un RamdomAccessFile afin de pouvoir faire un seek et écrire à la fin.

Le fait que VI ne lise pas le binaire c'est normal. Mais ce que je ne comprends pas c'est pourquoi le fichier est écrit en Binaire, je ne vois nul part ou je spécifie que ce soit écrit en binaire et pourtant c'est le cas.

En passant par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
 
// --- Ouverture fichier :
setWriter( new RandomAccessFile('nom_du_fichier'), "rw"));
 
// --- Ecriture dans fichier
getWriter().writeBytes('toto');

Ca ne fonctionne pas non plus (toujours écrit en binaire), alors qu'avec ces mêmes bout de code j'arrive à écrire un fichier XML et à le lire correctement sous VI (donc il est bien écrit).

[adiGuba]

Au départ j'ai fait avec un RamdomAccessFile afin de pouvoir faire un seek et écrire à la fin.

Tu peux utiliser le paramètre append sur les FileOutputStream...

Mais ce que je ne comprends pas c'est pourquoi le fichier est écrit en Binaire, je ne vois nul part ou je spécifie que ce soit écrit en binaire et pourtant c'est le cas.

Tout est binaire ! Un fichier texte est bien un fichier binaire qui utilise des séquences particulières pour représenter les caractères.

Ce qui est bizarre c'est qu'il me semble que l'UTF-8 est compatible avec l'US-ASCII et qu'il devrait donc être lisible par VI (au moins pour les caractères de base).

Ca ne fonctionne pas non plus (toujours écrit en binaire), alors qu'avec ces mêmes bout de code j'arrive à écrire un fichier XML et à le lire correctement sous VI (donc il est bien écrit).

Là je ne comprend plus : qu'est-ce qui marcher et qu'est-ce qui ne marche pas précisément ?

a++

[kij]

Oui exact excuse moi, j'ai pris la mauvaise habitude d'employer des mots pour des autres, ce qui donne ceci :

Binaire = EBCDIC
Non Binaire = ASCII


Ce que j'ai créé : une classe qui me permet d'écrire dans un fichier.
L'utilité que j'en ai : écriture d'un fichier de rapport, écriture d'un fichier xml après lecture d'un fichier d'info.

Ce qui passe : le fichier xml semble bon (lisible via VI)
Ce qui ne passe pas : le fichier de rapport n'est pas lisible sous VI, en tout cas j'ai l'impression que c'est encodé en EBCDIC au lieu de l'être en ASCII.


Explication de mon application :
Le programme java que j'ai fait est présent sur un serveur. Un job MainFrame le lance et récupère via FTP le rapport qui en découle afin de pouvoir l'envoyer par mail à un utilisateur.

Je travaille sous Eclipse / Window, j'ai donc testé mon prog sous window.
Résultats : Tous les fichiers sont "lisible" donc à priori encodé en ASCII.

Une fois mon projet transformer en JAR et installé sur mon serveur AIX, je lance le prog de la même que sous Eclipse, le prog tourne bien, les fichiers sont créés de la même manière à la différence que :
J'arrive bien à visualiser directement sous VI le fichier XML (donc encodé en ASCII), mais pas le fichier de rapport qui semble être encode en EBCDIC (en tout cas ca s'en rapproche.

Ayant le même code pour l'écriture dans un fichier, je ne comprends pas pourquoi sous AIX le résultat diffère pour le fichier de rapport.

[kij]

J'ai trouvé une solution de "rechange" :

Je vais passer par Log4j pour écrire mes fichiers de rapport, en définissant donc un logger pour chaque fichier de rapport.

Merci pour ton aide AdiGuda.

[adiGuba]

Juste un truc qui me chiffonne : si tu veux de l'ASCII pourquoi encodé en UTF-8 ???

a++

[iohack]

Tu ne travaillerais pas dans un centre informatique de la sécu ?
Sinon j'ai déjà eu ce genre de problème.
Pour faire propre, ne pas laisser à ftp le choix du mode de transfert, cela dépend visiblement du type de fichier source à récupérer (recfm fixe ou variable, lrecl, PDS, VSAM, etc.)
La méthode :
récupérer en mode binaire le fichier mainframe sur la machine AIX.
transcoder l'EBCDIC (IBM297 de son nom officiel de charset - si utilises comme je le pense MVS) en UTF8. Personnellement, travaillant sur de gros fichier j'utilise le package nio.
Cette méthode fonctionne très bien à mon boulot.