On Wed, Jun 2, 2010 at 5:29 PM, Branko Čibej <brane_at_xbc.nu> wrote:
>
> It's not really very magic. :) We have four sets of conversions:
> external to/from UTF-8, UTF-8 to/from filesystem path. I believe I
> misled you a bit.
Brane, thanks for the concise explanation of the assumed design.
unfortunately for z/OS, that isn't what the code is really doing. The
assumed UTF-8 in the middle is really a hodge-podge of real UTF-8 and native
literal strings and characters. But I was encouraged to see a recent post
asking how to test the encoding for a patch on an ASCII box to make sure it
was correct.
On Unix, external and filesystem-path use the same
> encoding; on Windows, filesystem-path is UTF-8 (converted as necessary
> to UTF-16 by APR). So we don't actually have a different set of
> functions just for console output conversions; but they could be added.
> Conversion from command-line parameters and interactive input (e.g.,
> passwords) to the internal UTF-8 encoding are tricky, too. I think we do
> them incorrectly in general on Windows, assuming too much about the
> external encoding.
>
> String literals are the worst part because no conversions are performed
> on them ...
*nods*
but we could add something to the _() macro and fix a lot of it.
> you mentioned NLS: all our translation files are in UTF-8,
> so if the literals within _() are in EBCDIC, none of the translations
> will work. Awfully hairy problem there.
>
yep.
I think the internal encoding could be made consistent without too much
trouble.
However, a simpler solution for now to get the basic svn functionality out
there for z/OS has already been done. It is to ignore the mixed encoding
and wave a magic wand and make EBCDIC go away internally to svn. I tried
that earlier without much luck, but it turns out there is a much more potent
magic wand than the one I used, as used by this patch posted to the svn
users list in 2006:
http://svn.haxx.se/users/archive-2006-11/0063.shtml
I started playing with this patch. so far, so good, but then I hit some
minor problem because I used 1.5.6 as my base. then &dayjob took me away
from it. the patch needs work before it could be committed, as the author
stated.
Dan, though you might be interested :)
Greg
Received on 2010-07-13 17:02:37 CEST