tags:

views:

361

answers:

2

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.

A: 

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

MSalters
+1  A: 

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...

fran