Paul Clapham wrote:Don't use a BufferedReader. If you do that, then the first time you read something from it, it will take 4096 characters (or whatever is the buffer size) from the underlying input stream and store it in a buffer (hence the name of the class). In your case you don't want it to read all those extra characters. So don't use buffering.
Jazlyn Lee wrote:
Paul Clapham wrote:Don't use a BufferedReader. If you do that, then the first time you read something from it, it will take 4096 characters (or whatever is the buffer size) from the underlying input stream and store it in a buffer (hence the name of the class). In your case you don't want it to read all those extra characters. So don't use buffering.
So what's wrong when I tried to read binary data of the image?
I still can't get the idea.
Mike Simmons wrote:
Jazlyn Lee wrote:
Paul Clapham wrote:Don't use a BufferedReader. If you do that, then the first time you read something from it, it will take 4096 characters (or whatever is the buffer size) from the underlying input stream and store it in a buffer (hence the name of the class). In your case you don't want it to read all those extra characters. So don't use buffering.
So what's wrong when I tried to read binary data of the image?
I still can't get the idea.
When the BufferedReader reads 4096 chars initially, that probably means it reads 4096 bytes from the BufferedInputStream "in". Let's say the first line takes about 100 characters - then when you call readLine(), the BufferedReader grabs 4096 characters, gives you the first 100 characters as the first line, and saves the remaining 3996 characters in its own internal buffer. Those remaining characters are still available from the BufferedReader, if you make additional calls to read() or readLine() - but they are gone as far as the BufferedInputStream is concerned. So when you go to in.read(), it starts reading from position 4096 (0-indexed). It's already passed on the preceding bytes to the BufferedReader.
(In this discussion I've been assuming a 1-byte encoding so that one byte becomes 1 character. Also I'm ignoring the InputStreamReader, which could also be hiding a few bytes along the way. Those are additional complications. But the basic problem can be understood best from discussing the BufferedReader only.)
What I would do is try to read everything from a BufferedInputStream. Read the first line one byte at a time, writing them to a ByteArrayOutputStream as you go, and looking for a \n. Once you read the \n, you've read the first line, and nothing else. Take the ByteArrayOutputStream, call toArray(), and then make a String from the byte array. That's your first line, as text. Now the BufferedInputStream is ready for reading as an image file.
Mike Simmons wrote:Not offhand. It looks good based on what you've told us. However there are many things you can check to see if they're behaving as you expect. For example: what is the command you're sending to the socket? And what is the response string? It may be an error message telling you there's a problem with the command. If not, look carefully at the last bytes of the text string, and also at the first few bytes of the image file. It's possible there's something there besides the bytes you expect. You can also look up the specification for whatever image format the image file is using, and see if you can interpret the first few bytes according to that specification. Lastly, can you obtain the image file through any other means, so you can compare it to the one your program writes? If you can find exactly how the files are different, that could greatly help in fixing the problem.