Mail Archives: cygwin/2009/05/13/11:18:36
On May 13 15:54, Andy Koppe wrote:
> > - why do you need to touch the filename at all? I haven't read all of it. Is
> > the UTF-16 on disk and we need to work around UTF-16 being intractable as C
> > string?
>
> Yes. If you simply treated each UTF-16 symbol as two chars, you'd get
> unintended NULs and slashes. For starters, the upper halves of all
> ISO-8859-1 characters are NUL in UTF-16. And even without that, the
> resulting filenames would be completely unusable.
Right. That's the crux when using UTF-16 filenames but many different
multibyte codepages. In contrast to a system in which the filename is
just a byte stream, we have to perform widechar to multibyte conversion
and outside of the UTF-8 domain, every other conversion is lossy.
For the time being, I applied a patch to Cygwin which should ease the
pain.
I followed the suggestion to use UTF-8 for internal conversions when the
locale is set to "C". This will also be used as default conversion when
converting the Windows environment from UTF-16 to multibyte, unless the
environment contains a valid LC_ALL/LC_CTYPE/LANG setting. The current
working directory was also potentially unusable, if an application
switched the locale. Now the CWD is re-evaluated after a setlocale call.
I'm sure this change doesn't fix all problems, but this worked much better
in my environment when using japanese and chinese characters in filenames.
There are a few other changes to the Cygwin DLL in the loop, but I will
update Cygwin 1.7 end of the week.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -