[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Is --enable-utf8 working everywhere?

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-07-15 19:58:32 CEST

Branko Čibej <brane@xbc.nu> writes:
> It doesn't even remotely work on Win32:
> apr_error: #20523, src_err 0 : <This function has not been implemented on this platform>
> (charset translator procurement failed)

Heh. Okay, that won't do.

> As you noticed in a previoue post, apr_xlate is very
> Unix-specific. Unfortunately, I don't even remotely have time to write
> a Win32 version.
> What's frustrating is that translating from any Windows locale to
> UTF-16 is trivial and supported by the Windows API, and code that
> translates between UTF-16 and UTF-8 is already in APR, and on NT-class
> platforms, APR will use UTF-8-encoded file names directly ...

Seems we have two choices:

   1. Ship with --enable-utf8 turned off, or at least turned off for
      Windows systems (but that's ugly, because the Subversion behaves
      differently depending on the client platform), or,

   2. Implement Win32 xlation. Given your second paragraph, fixing
      apr_xlate under Windows sounds like it's not a difficult task
      (since a first-pass implementation could just translate from
      locale to UTF-16 and then use apr to get from UTF-16 to UTF-8).
      It's just a matter of finding time to do it.

Comments, anyone? Are there options I haven't thought of?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 15 20:10:16 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.