[BufferedWriter] Ecriture fichier de log sous AIX

Version imprimable

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:

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:

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.

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:

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:

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 :

17/09/2007, 15h30
adiGuba
Salut,

Citation:

Envoyé par 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)

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

Citation:

Envoyé par kij

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:

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++
17/09/2007, 15h40
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:

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).

:(
17/09/2007, 15h54
adiGuba

Citation:

Envoyé par kij

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...

Citation:

Envoyé par kij

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).

Citation:

Envoyé par kij

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++
17/09/2007, 17h09
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.
18/09/2007, 11h35
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.
18/09/2007, 11h41
adiGuba

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

a++
21/09/2007, 15h11
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.