On 2013-06-14 12:43 CEST, Paul Moore wrote:
On 14 June 2013 11:11, M.-A. Lemburg ...wrote:
I'm not sure I follow. I've definitely had use cases for the proposed error handler in the past and have written my own set of tools to do such conversions.
Just as an extra data point, I have also had need for this functionality in the past. It is sometimes possible to use xmlcharrefreplace as an alternative, but having the "named" entities in the output is often useful for debugging, if nothing else.
The technicalities of HTML/HTTP encodings are not so much the issue here. Much of the output of programs that would use this functionality, while ultimately intended for consumption on the web, is often read in a text editor as part of debugging and review, if nothing else. For that purpose, readable output is very useful. And sticking to ASCII, while not essential, certainly helps in an environment like Windows where UTF-8 is *not* universal (whether it should be is really not the point here).
just to add to this: I have grown a hard wired reflex when handing over program source files to admins for deployment in windows operating system driven HTML/HTTP environments to: Ensure the admin has an editor at hand to check that the utf-8 clean encoded text files she received do not suddenly become BOM-ed under the radar just because the admin changed some local file path in a config file or the like and subsequently stored it "subconsciously". The time otherwise lost in hunting mystery effects counts in days but feels like weeks ... And yes, I often have to deliver utf-8 files to "ease" the HTML/HTTP handling chain, but in debugging situations IMO it seems to be good to easily resort a pure ASCII representation without writing extra routines for it. All the best, Stefan.