On Fri, Sep 21, 2007 at 03:27:57AM +0200, Roland Mainz wrote: > David Powell wrote: > > It simply means that if you assume the *parseable* output of this > > command is using the caller's encoding and character set, you are > > wrong. > > Erm, my concern is not about "parseable" output. My point is that the > output cannot be processed. If you put the into a file and then let the > shell read it it may not be able to recover from this kind of error
Stop right there. If you put UTF-8 into a file that will be read elsewhere (or even in the same process) in a context where something else is expected, well, then you lose. That has nothing to do with svcprop. It is perfectly OK for an interface to declare that "thou shalt provide UTF-8 input and this shall output UTF-8" and leave it to consumers of that interface to do any codeset conversions that might be required. Interfaces that perform codeset conversions automatically are certainly easier to use, but we do need a way to get the original data in any context without losing data. So having an interface that deals only in UTF-8 here is a good thing. > > Always emitting the UTF-8 encoded data is the only way for svcprop to > > *avoid* data loss. Exactly, though, to be fair, there are other ways: what matters is emitting an encoding of Unicode, such as UTF-8/16/32 or even punycode ;) Nico --
