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

Re: [svn] Recode problem

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-05-09 11:46:33 CEST

On Mon, 9 May 2005, Vincent Lefevre wrote:

> On 2005-05-08 21:17:31 -0500, Ben Collins-Sussman wrote:
> > I think you misunderstood Greg's question. GNOME may have a
> > convention that applications always *save* files in UTF8 encoding.
> > But it has no control over files that already exist. What happens
> > when I ask a GNOME application to open a file encoded in something
> > other than UTF-8? Does it "guess" at the encoding?
> I don't know. For instance, ROX-Filer (a GTK+ application, i.e. using
> the same GNOME convention) guesses the enconding (but I don't know
> how) and fixes it on the fly if possible (and enabled?). I don't know
> how the guess is done, but using the user's locale isn't necessarily
> the best solution as the filename may come from an external source.
> I think that the best solution is to give the choice to the user,
> just like what Emacs does for the encoding of text file contents.

The POSIX way of making filename encoding locale-dependent is
fundamentally broken IMO. But I don't think each tool can solve a system
problem. On POSIX systems, I think the best solution is to rely on the
locale like we currently do. People should set up their locale correctly
and ensure that filenames are in the encoding of the locale. Even if we
make the filename encoding configuraable, it is easy to wind up with
filenames with different encodings in the same WC.

If I understand correctly, OS X isn't pPOSIX conformatnt (but it could
easily be by setting up the locales correctly to use UTF8). Subversion
already handles systems where paths have a different encoding than the
locale (i.e. Windows NT and later). It seems to me like APR should learn
the fact that OS X always has UTF8 filenames. I don't know OS X, but this
sems to be a simple fx in apr_filepath_encoding. I don't know if APR has a
specific reason not to doit this way.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 9 11:41:07 2005

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.