Re: [AD] Allegro unable to deal with non ascii filenames |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] Allegro unable to deal with non ascii filenames
- From: Elias Pschernig <elias@xxxxxxxxxx>
- Date: Sun, 28 May 2006 14:19:31 +0200
On Sun, 2006-05-28 at 11:41 +0200, Grzegorz Adam Hankiewicz wrote:
> > > On Sat, 2006-05-27 at 22:40 +0200, Michal Molhanec wrote:
> > > > don't tell me that there is no way on Linux how to ask system
> > > > which system encoding is used and/or to convert string from/to
> > > > UTF-8 to the system encoding.
>
> I could look into the python source to see how they get the encoding,
> but AFAICS they do guessing, and glibc uses environment variables
> to avoid guessing incorrectly.
>
> On 2006-05-27, Chris <chris.kcat@xxxxxxxxxx> wrote:
> > For me, this is LANG="en_US.UTF-8" and passing UTF-8 data to the
> > file functions seems to work just fine (filetest shows all the
> > info properly, and ufile.c was changed to pass UTF-8 data instead
> > of ASCII.
>
> That's precisely the problem: I'm not using UTF-8, I'm using latin1,
> and ufile.c is incorrectly escaping my 8-bit characters as utf8
> escape sequences. That's only part of the problem. Even for you,
> if you use utf8, pack_fopen will uconvert_toascii your filename,
> making any character higher than 127 some odd caret symbol, which
> makes pack_fopen fail with -1 ENOENT on non ascii filenames.
>
What is your locale string? We can try to detect an encoding allegro
supports out of it maybe. E.g. if the environment variable "LC_ALL" or
"LANG" has the substring "UTF-8" in it, we use U_UTF8. If it has
"ISO8859-1" in it, we use U_ASCII. So as long as it is an encoding
supported by Allegro, it should work. With my patch, your testcase
already should work if you set the file encoding to U_ASCII - all it's
missing is the auto-detection. With that in place, the two functions can
be made internal functions.
So, basically, the file encoding would be detect in allegro_init, and
file names would be converted before passing to libc. For windows - we
would use an _al_open function like for Mac OS 9, which would use _wopen
or open, depending on OLD_WINDOWS - like in Chris' file names patch for
stat.
--
Elias Pschernig