You're right, and I agree that replacement characters are a better default than throwing errors.
But with replacement characters, having a UTF8 default with no indication that it is UTF8 would lead to confusion among newbies attempting to read binary files. If they write "foo.jpg" <file-reader> and it gives them garbage data, then they may not immediately realize that they're reading UTF8 -- after all, they didn't specify UTF8 anywhere in their program. So you can chalk up a point in favor of explicit encoding parameters :-) Slava Daniel Ehrenberg wrote: > This is no longer the case wrt throwing exceptions; for most > applications, it's more useful to put a replacement character in the > string when decoding than to throw an exception. I was planning on > implementing something so you could do "pathname" utf8 strict > <file-reader> to thrown an exception rather than pushing U+FFFD. But > this should not be the default, because it can lead to really stupid > errors like this one: > http://www.logilab.org/embed?url=http%3A//www.logilab.org/cgi-bin/hgwebdir.cgi/xmldiff/diff/e70c25f0eb08/debian/changelog > Here, an ascii decoding was used, and it threw an exception because > the file was apparently in UTF-8. A better action to take in most > cases is to display replacement characters. At least the user gets > *something*. It's even more useful in the case of a slightly corrupted > UTF-8 stream, something UTF-8 was designed to handle gracefully. > > (That wasn't meant as an argument one way or the other on encoding APIs) > > Dan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
