Question

I am retrieving Japanese characters from a data source and I want to return this data to Excel in an XLOPER. I am using a Japanese version of Excel 2003 (hence XLOPERs and not XLOPER12s).

wchar_t* pszW = OLE2W(bstrResult); //I have the data I am trying to copy in a CComBSTR

ULONG ulSize = ::WideCharToMultiByte( CP_THREAD_ACP, 0, pszW, -1, NULL, 0, NULL, NULL );                        

if ( ulSize )
{   
   char* tmp = new char[ulSize + 1];
   tmp[ulSize]='\0';
   ::WideCharToMultiByte( CP_THREAD_ACP, 0, pszW, -1, LPSTR( tmp ), ulSize, NULL, NULL );
   pszReturn = tmp;     
}
wchar_t* pwszOut = new wchar_t[bstrResult.Length () + 1];

//now turn it back to test that that the correct code page was used. For debugging purposes only!
::MultiByteToWideChar (CP_THREAD_ACP,0, LPSTR(pszReturn),-1,pwszOut,bstrResult.Length () + 1);

//pwszOut and bstrResult look the same in the debugger              
delete [] pwszOut;

The parameter pszReturn is assigned to an XLOPER. The problem I have is that “アフリカの女王” is displayed as “ƒAƒtƒŠƒJ‚Ì—‰¤” in Excel.

Manually setting the code page to 932 yields the same results as CP_THREAD_ACP so I think that that part is correct.

Any help would be greatly appreciated.

Was it helpful?

Solution

User Error!

The above code is good. The problem is that Excel was using the wrong code page. I hadn't set the language for non-unicode programs to Japanese in Control Panel.

The code now works for the English version of Excel too.

That was a day and a half well spent...

OTHER TIPS

A char* is a sequence of bytes, interpreted using the current charset. To be precose, that is the charset used by the party doing the interpretation. In this case, Execl is receiving a charset that should be interpreted using codepage 932, but instead Excel is using another codepage.

The solution, as always is Unicode, in Excel represented by XLOPER12

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top