Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The problem with doing things like this is that you are completely ignoring the encoding. Encoding is one of the reason why there are parallel IO hierarchies in Java: InputStream [sun.com]/OutputStream [sun.com] vs Reader [sun.com]/Writer [sun.com]. The latter understand characters, the former understand bytes. Unfortunately, every time you go near a Reader/Writer, you need to specify a character encoding. As a rule, I try to prefer Reader/Writer where I can.

    Classes to look at:

    • Thank you for the useful information!

      For the record, ByteArrayOutputStream.toString() does offer a version which specifies the character encoding as a parameter. But that's definitely something I wasn't thinking about (especially since I just wanted it for logging). My personal wiring is probably far too close to Paul Graham's recent unforgivable sin in making Arc ASCII-only for the taste of people around here, or anyone steeped in Java. It's something I'd prefer to leave as Somebody Else's Problem as much as possible. I love having Unicode around and knowing it buys me a lot; I'd just rather not have to ever think about it, and encodings is one place where that implementation is exposed.

      Of course, I'm positive that my employer wouldn't want me to ignore encodings or any other internationalization issue if I was handing strings back to production output, so I definitely need to understand this distinction between Reader/Writer and InputStream/Output Stream. Again, thank you for the useful information.

      To be honest, converting a stream to a String is a really useful thing to wrap up into a static utility method.

      Yeah, and it'd be really useful for somebody to clue the designers of the APIs into the fact that coupling accessing a value to outputting the value with side-effect methods is a bad design choice, too. :) But yes, I can see that would be good to have.

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • As to thinking about encodings, I'm completely in agreement with you — everything should use UTF-8!