I quite agree, and I did try to acknowledge that need in my reply. The point of my message is to balance the "real world, make it work", with the consequences and drawbacks of that approach, so people can make better decisions about when to compromise, what they risk by doing so, and perhaps make better choices about exactly how they handle such cases.
For example, blindly applying Jens' workaround to a broken UTF-8 stream isn't going to work well, as it's written for a broken ISO-8859-1 stream; the workaround there is similar but much more complex. And Kostya points out that sometimes asking the user to identify the correct encoding is a good choice. The problem with that here is that we have a mixed encoding, and I don't believe I've ever seen a UI that gives the end-user the ability to correct a partial encoding mismatch. (It would be a lot of development and user learning for what should be a rare situation). And also: to lean on the people foisting such things on them to fix them, and to be better equipped to educate them. I have no desire to blame the victims here! I just hope to help the victims understand the nature of their situation, and perhaps deal with it a little more effectively. There's also a larger meta-issue here. Working around such problems reduces the pressure to fix them. We've seen where that can lead us, in email formats, SMTP, IP, and most notably, HTML, where browsers that would accept some idiosyncratic notion of "anything they could guess at" resulted in a web filled with garbage pages that wouldn't parse consistently from browser to browser. (Not to mention browsers not following standards themselves -- a separate problem with similar results, as pages deliberately introduced bogosity to work around browser bugs). So I would encourage anyone finding themselves in this position to put pressure on the source of the problem. I'd even go so far as to suggest considering informing the user of the problem with the source, prior to offering a workaround. It would not always be possible or appropriate, but it may enlist the user in informing bad sites that they're broken, and it may also be important to alert the user to the corrupted data they will be viewing. But in the end, our responsibility is to our end users, and we have to consider what's best for them -- in both the short run and the long run. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
