Discussion :

[User Name]

Bonjour à tous,

Ca fait 2 jours que j'essaie d'apprendre avec les tutos sur Internet à lire dans un fichier texte ligne par ligne en Java.

Voici mon code:

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
17
18
19
20
21
22
23
24
			fis1 = new FileInputStream(conn);
			fis2 = new FileInputStream(reco);
			
			ipsr1 = new InputStreamReader(fis1);
			ipsr2 = new InputStreamReader(fis2);
			
			br1 = new BufferedReader(ipsr1);
			br2 = new BufferedReader(ipsr2);
			
			ArrayList<ArrayList<String>> gal = new ArrayList<ArrayList<String>>();
			ArrayList<ArrayList<String>> gal2 = new ArrayList<ArrayList<String>>();
			
			String rl = null;
			
			while ((rl = new String(br1.readLine()))!=null)
			{			
				System.out.println(rl);
				String[] s = rl.split(" ");
				ArrayList<String> al = new ArrayList<String>();
				Collections.addAll(al, s);
				gal.add(al);
				//rl = br1.readLine();
			}

J'ai cru comprendre que si je mets un "readLine" dans le while, il va passer à la ligne suivante. Alors j'ai fait comme ça.

Mais pour une raison que je me creuse la tête à comprendre, il s'arrête à l'avant dernière ligne de mon fichier texte et m'affiche un NullPointerException au niveau de la ligne en gras.

Merci pour vos lumières.

[User Name]

Bon, j'ai résolu le problème en mettant le "new String" avant la boucle while, mais par contre, il ne lit pas les 2 dernières lignes du fichier...

[Mathieu.J]

Bonjour,

Pour la lecture ligne par ligne il y a la FAQ :

http://java.developpez.com/faq/java/...eLigneParLigne


Pour le problème des 2 dernières lignes postes ton code à jour.

[professeur shadoko]

pourquoi faire new String(br1.readLine())
le code correct serait

Code :

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

1
2
 
while(null != (r1= br1.readLine()))

sinon quand readLine rend null tu as un NullPointerException

[thelvin]

mais par contre, il ne lit pas les 2 dernières lignes du fichier...

Elles n'existent sans doute pas.

Ou alors il y a un bug dans le reste de ton code, c'est possible aussi.

[User Name]

Je constate que mon dernier message n'a pas été posté...
Je disais qu'effectivement je n'avais pas fait gaffe, c'était des retours de ligne sans passer à une nouvelle ligne.

Par contre, j'en profite pour vous poser une autre question (j'ai cherché évidemment, mais comme je débute dans ce domaine, je comprends lentement):

J'ai utilisé un BufferedWriter (vu sur Internet) pour écrire dans un fichier.

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
17
18
19
20
ArrayList<Integer> temp_al2;
			for (int p=0; p<bytes.size(); p++)
			{
				t = bytes.get(p);
				bw.write(((char)(int)t));
				System.out.print(t);
				
				temp_al2 = hashmap.get(t);
				
				for (int q=0; q<temp_al2.size(); q++)
				{
					bw.write(temp_al2.get(q));
					System.out.print((int)temp_al2.get(q));
				}
				System.out.println();
				
				bw.flush();
				bw.newLine();
			}

Dans la ligne en gras, j'essaie d'écrire des "Integer" dans un fichier texte. Mais que je caste en char, int, byte ou autre, ils n'apparaissent pas. Les char de la première ligne grasse apparaissent, eux. Pourquoi?

Je n'arrive pas non-plus à comprendre la différence entre utiliser un BufferedWriter et un FileOutputStream (auquel je suis plus habitué).

Merci d'avance pour vos (r)enseignements. ^^

[druzy]

Je ne comprend pas bien ton problème de cast, apparition (où quand comment) mais ce que je peux te dire c'est que le bufferedWriter te permet d'écrire plus vite dans un fichier car comme son nom l'indique il utilise un buffer.

[User Name]

Et pourquoi mon BufferedWriter n'affiche pas mes int castés en byte puis en char dans mon fichier? Il écrit des espaces à la place... :/

[thelvin]

Bon, on commence par la base :

- un BufferedWriter c'est un sous-type de Writer.
- un FileOutputSream c'est un sous-type de OutputStream.

=> la différence qui t'intéresse c'est entre Writer et OutputStream.

Le point commun : les deux servent à écrire des choses.
La différence :
- un OutputStream sert à écrire des octets (type byte.)
- un Writer sert à écrire du texte, des caractères (type char ou String.)

Mais, va-t-on me dire, tout en informatique c'est des octets. Donc quoi qu'écrive un Writer il va forcément écrire des octets.
=> Oui, mais un OutputStream écrit les octets directement tels qu'on les lui donne. Alors qu'un Writer, il prend les caractères qu'on lui donne, il les transforme en octets à la volée, puis il les écrit. Cette transformation se fait avec un charset : en principe le charset avec lequel on a construit le Writer. Si on a pas indiqué de charset, alors le charset par défaut.

Exemples de différence concrètes :
- Dans certains charsets, le é prend un octet. Dans d'autres charsets il prend deux octets (et dans d'autres, quatre.) Alors qu'on ne lui a donné qu'un charactère, le Writer peut écrire un ou plusieurs octets. Un OutputStream, lui, écrit les octets qu'on lui donne.

- Dans le charset latin-1, le caractère japonais 日 n'existe pas. Si on le donne à un Writer qui écrit en latin-1, il réalisera qu'il ne peut pas convertir ce caractère en octets, et à la place il fera comme si c'était le caractère point d'interrogation '?'
Alors qu'un OutputStream, de toute façon on aurait casté les choses pour obtenir des bytes, et il ne se pose pas de question, il écrit les bytes qu'on lui donne.

Et pourquoi mon BufferedWriter n'affiche pas mes int castés en byte puis en char dans mon fichier? Il écrit des espaces à la place... :/

Pourquoi ça fait des espaces ça j'en sais rien. Sauf si les int valent 32, 32 c'est le code Unicode de l'espace donc là c'est normal.
Mais pour d'autres valeurs ça devrait faire d'autres caractères, qui n'ont pas l'air d'avoir de sens.

Pourquoi ? Parce qu'un char c'est exactement un caractère. Pas deux, pas trois, pas zéro, un. Un seul. Donc si tu essaies de cast un int qui vaut 27, tu ne peux pas le convertir en chars et penser que ça va écrire "27". Parce que 27 c'est composé de 2 et 7. Deux caractères. Plus d'un. Ça ne rentre pas dans un char. Ça ne peut pas marcher. C'est pas comme ça que ça fonctionne.
Il fallait convertir ton int en String, qui contient plusieurs caractères.
Avec String.valueof(tonEntier)

[User Name]

Merci pour ces explications détaillées.

Si j'ai bien compris ta logique, le code...

Code :

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

fos2.write((char)(temp_al2.get(q).byteValue()));

où temp_al2.get(q) est égal à 0 ou 1, est censé m'écrire dans le fichier de
sortie des 0 et des 1. Or, il continue de m'écrire de la poubelle, alors que
quelques lignes plus haut dans mon code,

Code :

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

fos2.write((char)temp);

où temp est un int qui contient bis.read(), fonctionne bien, lui et écrit les caractères proprement dans le fichier.

Pourquoi?

PS: fos2 est un FileOutputStream, mais si je le remplace par un BufferedWriter (pour être sûr d'avoir bien compris), j'ai le même résultat...

[thelvin]

Si j'ai bien compris ta logique, le code...

Code :

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

fos2.write((char)(temp_al2.get(q).byteValue()));

où temp_al2.get(q) est égal à 0 ou 1, est censé m'écrire dans le fichier de
sortie des 0 et des 1.

Absolument pas. Il est censé t'écrire le caractère NUL (0x00) et le caractère Start Of Header (0x01,) les deux premiers caractères de contrôle de la table ASCII et Unicode, dont les codes sont respectivement 0 et 1.

Sur ces mêmes tables on voit que les caractères qui sont les chiffres '0' et '1' ont pour code 48 et 49.

Or, il continue de m'écrire de la poubelle, alors que
quelques lignes plus haut dans mon code,

Code :

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

fos2.write((char)temp);

où temp est un int qui contient bis.read(), fonctionne bien, lui et écrit les caractères proprement dans le fichier.

Pourquoi?

Parce que la manière dont tu as obtenu le caractère temp a du sens.
Tu lis un fichier octet par octet, pour chaque octet ça te donne un int. Ce fichier est un fichier texte, probablement entièrement en ASCII.
En ASCII tous les caractères font un octet, et leurs codes Unicodes sont les mêmes que leur code ASCII.

Donc les int obtenus sont valables pour être castés directement en char. C'est le cas uniquement parce que c'est un fichier texte ASCII. (ou latin-1, ça marcherait aussi pour raisons similaires.)

Par contre, sortir de son chapeau un int de valeur zéro ou un et le cast en char, ça n'a pas de sens. Ce ne sont pas des codes de vrais caractères. Il fallait utiliser '0' et '1' pas 0 et 1.

PS: fos2 est un FileOutputStream, mais si je le remplace par un BufferedWriter (pour être sûr d'avoir bien compris), j'ai le même résultat...

Normal. Writer est censé aider à différencier l'écriture d'octets ou de caractères. Pas corriger les bugs de programmation.

[User Name]

Bon, ben je vais regarder tranquillement si j'ai le temps, et je vous tiens au courant. Merci en tout cas pour ces explications.