解决非Unicode编码的软件多语言版本在日语、韩语环境下的乱码问题

在第一次为公司的客户端软件定制日语版本的时候，由于软件开发是非Unicode版本的，发现当加载日语后，无论是在中文操作系统还是在日语操作系统下，软件界面上的大部分日语显示的都是乱码。在上网查看了相关的知识文档和案例，结合目前我们软件的开发环境和具体的代码实现，找到了两种解决办法。

第一种：

就是将整个软件工程变为Unicode编码格式。虽然这种方法能从根本上实现软件的国际化多语言版本。但修改起来工作量相当的庞大。例如：整个软件源码中以前采用只支持ANSI编码的字符串操作函数（如strcpy(),strlen()）都要改为支持Unicode的（如wcscpy(),wcslen()），或者换成ANSI和Unicode通用的字符串操作函数。

第二种：

就是具体问题具体分析。就目前出现的乱码情况来看。主要是重载、自绘的控件出现了日语的乱码。其解决办法是首先对需要输出的字符串进行编码格式的转换，然后将字符串输出函数换为后缀为W的（即支持宽字符集的）字符串输出函数。

问题分析：

非 UNICODE 程序在不同语言环境间移植时的乱码

非 UNICODE 程序中的字符串，都是以某种 ANSI 编码形式存在的。如果程序运行时的语言环境与开发时的语言环境不同，将会导致 ANSI 字符串的显示失败。

比如，在日文环境下开发的非 UNICODE 的日文程序界面，拿到中文环境下运行时，界面上将显示乱码。如果这个日文程序界面改为采用 UNICODE 来记录字符串，那么当在中文环境下运行时，界面上将可以显示正常的日文。同样，对在中文环境下开发的非 UNICODE 程序同样存在此问题。

解决办法：

第二种方法的具体解决方案如下：

1、主要的字符串编码格式转换函数

[c-sharp] view
plaincopy

DWORD CNetAppSoftDlg::MByteToWChar(LPCSTR lpcszStr, LPWSTR lpwszStr, DWORD dwSize)

{

//获取该字符串转换成Unicode编码格式需要的buffer的大小

DWORD dwMinSize;

dwMinSize = MultiByteToWideChar (CP_ACP, 0, lpcszStr, -1, NULL, 0);

if(dwSize < dwMinSize)

{

return -1;

}

//将ASCII转换为Unicode.

MultiByteToWideChar (CP_ACP, 0, lpcszStr, -1, lpwszStr, dwMinSize);

return dwMinSize;

}

2、具体的使用：

[c-sharp] view
plaincopy

void CNetAppSoftDlg::TextOutW_EX(HDC hDC, CRect cRect, CString csText)

{

wchar_t wchCaption[256];

ZeroMemory(wchCaption, 256);

char chCaption[512]= {0};

sprintf(chCaption, "%s", csText);

DWORD dwMinSize = -1;

dwMinSize = MByteToWChar(chCaption,wchCaption,256);

if (-1 == dwMinSize)

{

AfxMessageBox("Conver failed!", MB_USERDEFINE);

}

else

{

TextOutW(hDC, cRect.left, cRect.top, wchCaption, dwMinSize-1);

}

}

建议：

第一，以后编写软件创建工程的时候，都要采用Unicode的编码格式，因为它对各种语言都是通用的，是软件走向国际化的标准方式。正如Unicode的产生背景一样，我们软件的开发也要随之变化以适应新的应用环境。

第二，在以后编码的过程中，使用通用的（同时支持ANSI和Unicode，以_tcs或者lstr开头）的字符串操作函数，如_tcscpy(),lstrcpy()。