Here a simple code which I have to add on project:

import java.io.*;
import java.util.Scanner;
public class Ana {
	static public void main(String[] args)
	{
		try{
		File gecicidosya=new File("D:\\B.txt");
		File sdosya=new File("D:\\A.txt");
		Scanner oku = new Scanner(sdosya);
		BufferedWriter yaz=new BufferedWriter(new FileWriter(gecicidosya));
		while(oku.hasNextInt())
		{
			System.out.println("while started");
		 oku.nextInt();
			System.out.println("file readed");
		}
		oku.close();
		yaz.close();
		System.out.println("finish");
		}
		catch(Exception e)
		{
			System.out.println("problem  "+ e);
		}
	}
}

But it does not work :( It does not give any error. It writes "finish" but even D:\\A.txt is about 60kb while(oku.hasNextInt()) doesn't work :( Can you please help me about it ? (I use "scanner" instead of bufferreader because bufferreader cannot scan for integer. anyway that it is not important)

Thanks!

I'm so sorry. I want to delete this thread but I can't. Can you please tell me how to delete a thread which has never answered? Thanks

You can't. By joining Daniweb and posting a thread here, you agreed that your code will be publicly visible. I can/will only delete threads when they violate our rules in such a manner that this would be the only option. (so spam, profanity, copied stuff etc).

I assume that the file D:\\A.txt has integers inside it. Can post part of the contents of that file.

Also this is how it is declared with the public first:

public static void main(String[] args) {

}

But I am surprised that you said that it compiles.

The file is exist of course. javaAddict I don't understand what you mean with " D:\\A.txt has integers inside it" because the file is about 60 kb. So when I read an integer, it reads two bytes from file. So it is not possible to tell me that there is no integer. Am I right ? I mean FileReader I know that can not understand if the next argument is an integer or character... When we write integer it reads two bytes and for character reads 4 bytes... And it look for bits integer 8x2=16 bits for integer example: 0000..000011 = 3.

The file is exist of course. javaAddict I don't understand what you mean with " D:\\A.txt has integers inside it" because the file is about 60 kb. So when I read an integer, it reads two bytes from file. So it is not possible to tell me that there is no integer. Am I right ? I mean FileReader I know that can not understand if the next argument is an integer or character... When we write integer it reads two bytes and for character reads 4 bytes... And it look for bits integer 8x2=16 bits for integer example: 0000..000011 = 3.

Actually no.
You are using the Scanner class. When you call the nextInt method, it reads an integer:
File Contents:

1 2 33

It does not read the bytes of the file.
If you want to read the bytes of the file use a different class.
If you want to read the entire line as String use the nextLine method.
Every file (.avi files, image files) can have their contents represented in bytes.
But the method you are using doesn't read bytes. It expects to find integers.

What is the format of your file and what do you want to?

I try to read integer from (any file type of a file) and it worked with RandomAccessFile.
Now I want to read by one one the integers from file. But I could not find any hasNext function on RandomAccessFile libary :( I need it because I want to read all files on integer like that :

while(myreader.hasnext){ myint = myreader.readInt(); ..... }

but there is no has next on RandomAccessFile libary as I said.

If you want to read all of the ints from a File one by one then use Scanner and use the nextInt method. If you want to read an int using RandomAccessFile, it has a readInt method.

But Scanner can't read ineger from file. It does not show even the "abc" :

while(scanner.hasNext) { println("abc") ... }

But the same file can read by Random Access file.That is my problem! :(

The code you just posted won't even compile. Even if it did, the hasNext() method does not advance past any input so I'm guessing that would be an infinite loop.

1. Use hasNextInt() to see if the next token in the input is an int
2. If it is not an int, use

if (scanner.hasNext()) scanner.next();

3. Repeat.

if (scanner.hasNext()) scanner.next();

it is not working :

Exception in thread "main" java.lang.Error: Unresolved compilation problem:
The local variable a may not have been initialized

at Ana.main(Ana.java:15)


I don't know but Scanner does not working ehn I want to read integer.
But Random Accses file is working but random acsess file has not a like "hasnext" function. That is the problem.
Look let me explain again: There is a file on D:\A.something This file is saved on my hdd as 10010101011010101010101010101011000011110............
I want to read the first two bytes as integer. And then I will convert the integer to binary mode to see the first 16 bits of this file. And to print on the screen. Is this so difficult ? :( (it is not important which filetype is, and also it is not important to read two bytes from file, but it can read 4 or one byte if I can see it as integer (so I can convert it to binary base) )...

You get that error not because the Scanner class is not working, but because your code doesn't compile.
Have even tried to read that error message:?

The local variable a may not have been initialized

Ana.java:15

Now what do you need to do in order to fix that?

It is important what is the file type. Even if its extension isn't .txt, if it contains text like this:
10010101011010101010101010101011000011110............
then the Scanner can read it. Scanner.nextLine. Check the Scanner's class API

Then just read the first line as String. Then use substring to get any number of bits from that line:
1001 or 10010101 and use the Integer class in order to convert that into decimal. Check the Integer's class API

Also when you say that you want the above to be converted into binary doesn't make any sense since it is already in binary.

javaAddict If I use Scanner.nextLine, so it will not read the file as binary but as character string. I mean if I use Scanner.nextLine the filetype is important for me because you can not read the 1s and 0s if they are not on the file.
I dont understant how the filetype is important when I want to read a character or integer from a file ? That is something impossible for me . I know that every file is saning on my harddisk as 1010101111011011............. and when I open the file with mp3player it reads the bits as what mp3 player wants to do. When I open it with "txt viewer" it reads (i don't know exactly and it is not important now) first 4 bytes for first character, and second 4 bytes for second character and shows me them on the screen. And I tell you that I want to read any file as I want to read. For example first 4 bytes (4*8 bits) is a long integer for me. Or the second 1 byte is a just a key for my grafic interface color ... or something. And I tell you that there is I way to show the bits of file on the screen. I think that if I can read the first two bytes as integer and I convert it on binary base I would be able to see the file as binary. If my suggestion is false can you tell me how to do it on another way ?

Then you need to take a look at the FileInputStream class

javaAddict If I use Scanner.nextLine, so it will not read the file as binary but as character string. I mean if I use Scanner.nextLine the filetype is important for me because you can not read the 1s and 0s if they are not on the file.
I dont understant how the filetype is important when I want to read a character or integer from a file ? That is something impossible for me . I know that every file is saning on my harddisk as 1010101111011011............. and when I open the file with mp3player it reads the bits as what mp3 player wants to do. When I open it with "txt viewer" it reads (i don't know exactly and it is not important now) first 4 bytes for first character, and second 4 bytes for second character and shows me them on the screen. And I tell you that I want to read any file as I want to read. For example first 4 bytes (4*8 bits) is a long integer for me. Or the second 1 byte is a just a key for my grafic interface color ... or something. And I tell you that there is I way to show the bits of file on the screen. I think that if I can read the first two bytes as integer and I convert it on binary base I would be able to see the file as binary. If my suggestion is false can you tell me how to do it on another way ?

You've said about 100 times in this thread that you want to read in an integer. Now you're changing your mind and saying you want to read in binary?

It doesn't matter how Scanner interprets something correctly, it just does. By worrying about the underlying implementation when you want to accomplish a specific task, you're wasting your time. Just read the documentation. Scanner tells you it knows how to read in ints, chars, Strings, etc, and that is all that matters. Ex: this code will read in all the integers from a file.

Scanner input = new Scanner(new File("your exact file path goes here"));
while(input.hasNext()){
if (input.hasNextInt()){
System.out.println(input.nextInt());
} else System.out.println(input.next());
}

You've said about 100 times in this thread that you want to read in an integer. Now you're changing your mind and saying you want to read in binary?

It doesn't matter how Scanner interprets something correctly, it just does. By worrying about the underlying implementation when you want to accomplish a specific task, you're wasting your time. Just read the documentation. Scanner tells you it knows how to read in ints, chars, Strings, etc, and that is all that matters. Ex: this code will read in all the integers from a file.

Scanner input = new Scanner(new File("your exact file path goes here"));
while(input.hasNext()){
if (input.hasNextInt()){
System.out.println(input.nextInt());
} else System.out.println(input.next());
}

From his latest post I understood that miles.85 wanted to print the bytes of the file, that is why I suggested that class. Anyway both solutions are correct and it's up to miles.85 to choose what he want.
To read only integer the contents of the file with Scanner or the bytes of the file, no matter what file it is.

To read only integer the contents of the file with Scanner or the bytes of the file, no matter what file it is.

Not saying you are wrong, you obviously know what you're talking about - but that sentence confuses me - could you rephrase, please? An integer is 32 bits so it would actually matter whether he chose to read in bytes or ints.

You are right it doesn't make any sense.
I was saying,

> If he wanted to read the integer contents of the file to use the Scanner. I think that if the file doesn't contain text, you cannot use the Scanner class to read it. I don't know about the last one.

> If he wanted to read the bytes of the file no matter what is the file type use the FileInputStream.

I also believe/think that if a file contains numbers, then you will get different results if you try to read those numbers with Scanner and if you try to read the bytes of the file with FileInputStream

FileInputStream reads bytes of data. A byte could hypothetically represent any type of data - an int, a character, etc. The Scanner class is already set up so that the underlying code uses Regular Expressions to determine what the next type of data is. So if you call hasNextInt() it is going to always return true if the next piece of data (that matches the delimiter pattern) is an integer. And it will always return false otherwise. That is why I recommended that the OP use hasNext() to see if there is another piece of data in the file, and that he use hasNextInt() to further determine if this piece of data was or was not an integer. Btw, the delimiter pattern by default matches whitespace, which is determined by what the Character.isWhitespace method says is whitespace.

Thank for you interest!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.