Solve the Problem of garbled characters in Japanese and Korean languages for non-Unicode-encoded software multilingual versions

When I first customized the Japanese version for the company's client software, since the software development was not a unicode version, I found that after loading Japanese, whether in a Chinese operating system or a Japanese operating system, most of the Japanese on the software interface are garbled characters. I checked the relevant knowledge documents and cases online, and found two solutions based on the current software development environment and specific code implementation.

 

First:

It is to convert the entire software project to the Unicode encoding format. Although this method can fundamentally achieve the international multilingual version of the software. However, the modification workload is quite large. For example, in the source code of the software, the string operation functions (such as strcpy () and strlen () that only support ANSI encoding) must be changed to Unicode (such as wcscpy (), wcslen (), or a string operation function for ANSI and Unicode.

 

Second:

Is the specific analysis of specific issues. We can see the garbled characters currently. This is mainly because of garbled characters in Japanese in the heavy-load and self-painted controls. The solution is to first convert the encoding format of the string to be output, and then convert the string output function to the string output function with the suffix W (that is, the wide character set is supported.

 

Problem Analysis:

 

Non-Unicode program garbled characters during transplantation between different language Environments
Strings in non-Unicode programs exist in some ANSI encoding format. If the language environment for running the program is different from that for development, the display of ANSI strings fails.
For example, when a non-Unicode Japanese program interface is developed in a Japanese environment and runs in a Chinese environment, garbled characters are displayed on the interface. If the Japanese program interface is changed to Unicode to record strings, the interface will display normal Japanese when running in a Chinese environment. This problem also exists for non-Unicode programs developed in Chinese environments.

Solution:

 

The solution for the second method is as follows:

 

1. Main string encoding format conversion functions

 

 DWORD cnetappsoftdlg: mbytetowchar (maid, lpwstr lpwszstr, DWORD dwsize) <br/>{< br/> // obtain the buffer size required for converting the string to unicode encoding format <br/> DWORD dwminsize; <br/> dwminsize = multibytetowidechar (cp_acp, 0, lpcszstr,-1, null, 0); </P> <p> If (dwsize <dwminsize) <br/>{< br/> return-1; <br/>}< br/> // convert ASCII to Unicode. <br/> multibytetowidechar (cp_acp, 0, lpcszstr,-1, lpwszstr, dwminsize); <br/> return dwminsize; <br/>}

2. Specific usage:

 

Void cnetappsoftdlg: textoutw_ex (HDC, crect, cstring cstext) <br/>{< br/> wchar_t wchcaption [256]; <br/> zeromemory (wchcaption, 256); <br/> char chcaption [512] = {0}; <br/> sprintf (chcaption, "% s", cstext ); </P> <p> DWORD dwminsize =-1; <br/> dwminsize = mbytetowchar (chcaption, wchcaption, 256 ); </P> <p> If (-1 = dwminsize) <br/> {<br/> afxmessagebox ("conver failed! ", Mb_userdefine); <br/>}< br/> else <br/>{< br/> textoutw (HDC, crect. left, crect. top, wchcaption, dwMinSize-1); <br/>}< br/>}

 

 

Suggestion:

 

First, when writing software to create a project, the Unicode encoding format will be used in the future, because it is common to various languages and is a standard way for software to become international. Just like the background of Unicode production, our software development needs to change accordingly to adapt to the new application environment.

Second, in the future encoding process, use a general string operation function (both ANSI and Unicode are supported, starting with _ TCS or lstr), such as _ tcscpy (), lstrcpy ().