<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT face=Arial size=2>Hi Frank,<BR><BR>> There is currently no suppot in
GDAL for wide strings, or<BR>> wide string filenames. As far as I
know<BR>> fopen() is the only low level open function used by GDAL<BR>>
(well there might be a few exceptions in sublibraries using<BR>> open()
instead).<BR><BR>Yes, fortunately the problem seems isolated to fopen(),
hopefully due to that, we can find a single-point fix. It's good that the
resulting FILE* is no different regardless of the filename's charset or how it
was opened.<BR><BR>> > Another option is for me to open the file first,
e.g. for Windows:<BR>> >
std::wstring fname;<BR>> >
FILE *fp = _wfopen(fname, L"rb");<BR>>
> int fd =
_fileno(fp);<BR>> > Then i could pass the fd into GDAL, if it had a way of
accepting it.<BR>><BR>> There is no support for this in GDAL.<BR><BR>That
might be a (relatively) painless solution then - for a the few places in GDAL
that take a (const char *) filename, a second entry point that take a (FILE
*). I will explore this option, but you may already understand the
ramifications better?<BR><BR>> For something like CSLLoad(), it is easy
enough to<BR>> reimplement yourself. But it is a big issue for all
the<BR>> files opened through GDALOpen().<BR><BR>Might be. I hope not
too bad.<BR><BR>> Actually, in thinking about it, you could in theory
implement<BR>> some sort of special VSI*L handler that knows how to
handle<BR>> wide strings.<BR><BR>But the methods above it (like CSLLoad)
would still need to accept the wide string in order to pass it on to the VSI*L
handle, i think?<BR><BR>> Are you sure there isn't someway of turning wide
string<BR>> filenames into something compatible with<BR>> fopen() on
windows?<BR><BR>Nope, fopen() on Windows (and most Unices, AFAIK) assume that
the (const char *) is in the current charset (local code page,
multi-byte). This means you can open chinese-name files on a
chinese-locale OS, and euro-names on a euro-locale OS, but not any other
situation. That puts on a damper on international file exchange, the
problem i am trying to fix.<BR><BR>> I have tried opening a variety
of<BR>> unusual filenames in different character sets, including<BR>>
double byte names, on windows successfully (I think). I<BR>> believe I just
passed whatever got passed in as a filename<BR>> after using shell
completion.<BR><BR>What shell are you using? <BR>I tried with
cygwin, and this is what i get. I made a couple sample files, one with
western europe non-ASCII characters, and one with Chinese characters. When
i 'ls', the non-ASCII are displayed as question marks:<BR><BR>$
ls<BR>??City.dem Pa?sCatalu?a.dem<BR><BR>That should be
(Bei)(Jing)City.dem, and PaísCataluña.dem (accent on i, tilde on n).</FONT></P>
<P><FONT face=Arial size=2>Using the shell completion, it works for the western
europe name (since that's my machine's locale) but fails for the Chinese:
The shell apparently tries to make escape sequences:</FONT></P>
<P><FONT face=Arial size=2>$ gdalinfo Pa\355sCatalu\361a.dem<BR>Driver:
USGSDEM/USGS Optional ASCII DEM (and CDED)<BR>Size is 374, 466<BR>Coordinate
System is: [....]</FONT></P><FONT face=Arial size=2>
<P><FONT face=Arial size=2>$ gdalinfo \?\?City.dem<BR>ERROR 4: `??City.dem' does
not exist in the file system,<BR>and is not recognised as a supported dataset
name.<BR></FONT><FONT face=Arial size=2>GDALOpen failed - 4</FONT></P>
<P>This could be the limitation of Cygwin's default command line, but even
if the command-line handled it, we know it would fail when it gets to
GDALOpen.</P>
<P>-Ben</P></FONT></BODY></HTML>