Hi, I’m updating the HDF5 C library that is used within IDL. We’re going from HDF5 v1.10.5 to v1.14.3. It looks like in version 1.12 support was added on Windows systems for UTF-8 filenames when opening/creating HDF5 files. This is fantastic - thanks for doing that - it seems to work great.
However, there doesn’t seem to be a fallback case for non-UTF8 filenames. Looking in H5system.c, it tries to use MultiByteToWideChar to convert from UTF8 to UTF-16. If this fails then it just bails and doesn’t open the file. We’ve got a Japanese Windows test machine that uses Shift-JIS as its native encoding. For filenames with ASCII characters everything is fine. But if the filename (or folder) has any Japanese characters then H5Fcreate and H5fopen fail miserably.
I could workaround this with some complicated pre-conversion, but I have no idea what codepage the filenames might be using. In our other wrapper code (for reading TIFF or PNG files), we try the MultiByteToWideChar and if it fails, then we just open up the file using the normal Windows non-wide _open. This works fine for Shift-JIS.
Am I missing something, either in compiling the library or my usage?
If not, it would be great if the HDF5 C library could follow a similar pattern: try MultiByteToWideChar (with CP_UTF8) first, and then rather than failing completely, fallback to simply calling _open rather than _wopen.