ASCII and binary will both be treated differently, yes, so you should use the one you mean. Binary streams for text is usually harmless, but text streams for binary just doesn't work. Be aware that the code you posted isn't designed in particular to read in either ASCII or binary -- it will decode files according to your default character encoding, which is likely to be (but isn't necessarily) a superset of ASCII. To get a pure ASCII BufferedReader for a file, you'd write something like this:
If by ASCII you simply mean text then the default character encoding should suffice.
To amplify David's answer to the original question - the code shown is definitely a Bad Idea™ for reading binary data such as an image file. First - why would you ever want to treat an image as a String? Second, even if you do getBytes() or something like that later on to convert the String back to something useful - you risk corrupting the data. Most of the time you may observe no problems, but every so often, things will be screwed up. In part this will depend on your platform's default encoding (unless you explicitly provide an encoding, which is almost always a good idea for text data that came from some other machine). But there's also a problem with BufferedReader's readLine(), because it can split lines on several different types of line separators - "\r", "\n", or "\r\n". You don't know which kind was provided, and your code is replacing them all with "\n". That's fine for text data, because those different line separators were probably intended to mean the same thing anyway. But for binary data, a "\r\n" probably wasn't intended to be a line separator at all. It was two consecutive bytes 0x0D0A, which just happen to look like a line feed to a Reader. But when you replace "\r\n" (0x0D0A, two bytes) with "\n" (0x0A, one byte) you're subtly changing the data. Perhaps not so subtly, since the position of all subsequent bytes will shift by one, which could produce massive errors from some file formats. So, as David said - don't treat binary data as if it were text; it isn't, and you can cause serious problems doing this. Even if it's not apparently a problem most of the time. I agree with Trent too; I'm just less concerned with performance than I am about data corruption, in most cases.