> Tatsuo Ishii <ishii@postgresql.org> writes:
>> My idea is using mule-internal encoding for the log file instead of
>> UTF-8. There are several advantages:
>
>> 1) Converion to mule-internal encoding is cheap because no conversion
>> table is required. Also no information loss happens in this
>> conversion.
>
>> 2) Mule-internal encoding can be handled by emacs, one of the most
>> popular editors in the world.
>
>> 3) No need to worry about locale. Mule-internal encoding has enough
>> information about language.
>
> Um ... but ...
>
> (1) nothing whatsoever can read MULE, except emacs and xemacs.
>
> (2) there is more than one version of MULE (emacs versus xemacs,
> not to mention any possible cross-version discrepancies).
>
> (3) from a log volume standpoint, this could be pretty disastrous.
>
> I'm not for a write-only solution, which is pretty much what this
> would be.
I'm not sure how long xemacs will survive (the last stable release of
xemacs was released in 2009). Anyway, I'm not too worried about your
points, since it's easy to convert back from mule-internal code
encoded log files to original encoding mixed log file. No information
will be lost. Even converting to UTF-8 should be possible. My point
is, once the log file is converted to UTF-8, there's no way to convert
back to original encoding log file.
Probably we treat mule-internal encoded log files as an internal
format, and have a utility which does conversion from mule-internal to
UTF-8.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
