On unix, file systems don't define the encoding of file names. A file name consists of any byte excluding /. When Oracle libraries are in a EUC-JP encoded directory, oracleClientLibDir must be a EUC-JP encoded string even if the locale encoding is UTF-8. Well, I think file name encoding is almost UTF-8 nowadays, though.
On Windows, both must be a null-terminated string encoded by the current Windows ANSI code page, which is CP932 on Japanese-version Windows, CP1252 on English-version Windows. That's because both are passed to ANSI-version functions; LoadLibraryA and SetEnvironmentVariableA respectively. (ODPI-C calls LoadLibrary and SetEnvironmentVariable, which are mapped to ANSI-version.)
Both
dpiContextCreateParams.oracleClientLibDir
anddpiContextCreateParams.oracleClientConfigDir
are documented as "A null-terminated UTF-8 encoded string defining the location ...". However I don't think so as far as I looked the source code.On unix, file systems don't define the encoding of file names. A file name consists of any byte excluding
/
. When Oracle libraries are in a EUC-JP encoded directory,oracleClientLibDir
must be a EUC-JP encoded string even if the locale encoding is UTF-8. Well, I think file name encoding is almost UTF-8 nowadays, though.On Windows, both must be a null-terminated string encoded by the current Windows ANSI code page, which is CP932 on Japanese-version Windows, CP1252 on English-version Windows. That's because both are passed to ANSI-version functions;
LoadLibraryA
andSetEnvironmentVariableA
respectively. (ODPI-C callsLoadLibrary
andSetEnvironmentVariable
, which are mapped to ANSI-version.)If this isn't a documentation issue but a bug, Unicode-version functions must be called on Windows.
MultiByteToWideChar
withCP_UTF8
.LoadLibraryW
orSetEnvironmentVariableW
.