First: Tks for commenting.
<short answer begin>
YES, maybe you are right: I think tak_deco_lib doesnt support multibyte correctly; and
almost NO, maybe you are wrong: I think tak_deco_lib doesnt support multibyte at all.
<short answer end>
I naturally agree with you about MBCS, UNICODE and UTF-8 relationships. I agree with this too: it's a problem guessing code pages from unicode, and moreover I doubt that even so it would work due to FS implications.
It seems easier using tak_SSD_Create_FromStream.
Just note:
char fileName [MAX_PATH];
const wchar_t wFilename[] = L"C:\\TestFile_\x0107.tak"; // N.B.: \x0171 is 'ć'
WideCharToMultiByte(CP_UTF8, 0, wFilename, -1, fileName, MAX_PATH, 0, 0);
fileName will be "C:\TestFile_ć.tak", shown as char string, not MB, where 'Ä' is 0xc4 and '‡' is 0x87.
Using above code you'll get the right MB string, but passing it to tak_SSD_Create_FromFile you'll get an invalid stream decoder.
As tak docs say and as tak behaves, it really seems TAK wants a simple char (not MB) string.
Naturally using CP_ACP (current system Windows ANSI code page) does not help; on my system (Italy) it converts 'ć' to 'c' and tak_SSD_Create_FromFile won't find the file.
You can play with WC_NO_BEST_FIT_CHARS flag (leading to this substitution 'ć' -> '?') but tak_SSD_Create_FromFile refuses to open.[/size]