Today, the second article, which I'm going to introduce, is about the issues associated with Unicode encoding and ASCII coding in Windows programming.
I do not know you novice friends encounter such a problem did not, a new Windows application, call MessageBox this function, ready to let it pop up a hint of text, but the compiler at compile time but the error said, can not be a const char* or const char[] To a hint like const wchar_t*, many friends who have just come in contact with Windows API programming may be stuck here and don't know how to solve it, which is the problem with Unicode encoding and ASCII coding. I'm going to go down the road.
About Unicode and ASCII specific encoding is how, I do not detail here, also can not introduce, if need to in-depth understanding, there are a lot of special articles on the Internet, I am here only for Unicode encoding and ASCII encoding in the Windows platform of programming related to Content to introduce.
We all know that the biggest difference between Unicode and ASCII is that Unicode uses 2 bytes to store a single character, whether in English, Chinese, or other countries, with 2 bytes to encode, and ASCII to store one character in one byte, so for the English encoding, That is enough, but for the encoding of Chinese characters, there must be some special way of using 2 ASCII characters to represent a Chinese character.
We are in the process of writing programs, it is bound to deal with characters, to enter, get, display characters, in the end is the choice of Unicode characters or ASCII characters, this is the right of all of you. However, Unicode encoding is recommended for the versatility of the program and the prevailing trend of the current operating system. Because Unicode characters are one-fold larger than ASCII characters, compiled programs must be larger in size and memory, but this is not a big problem. So Microsoft's current SDK retains 2 sets of APIs, a set of programs that use Unicode code to process characters, and a set of programs that use ASCII code to process characters. For example, the MessageBox we mentioned above is actually not a function name, but a macro definition, so let's look at how it's defined before we discuss it.
#ifdef UNICODE
#define MESSAGEBOX MessageBoxW
#else
#define MESSAGEBOX MessageBoxA
#endif
You see that? It's very simple. If you define Unicode, then define MessageBox as MessageBoxW, and if you don't have a Unicode macro defined, then define MessageBox as MessageBoxA, The W and a at the back of the messagebox represent wide-byte (Unicode) and ASCII, so that the functions that actually exist in the SDK are the functions of MessageBoxW and MessageBoxA.
MessageBox is just a macro. So in the program, you can use these 3 names, but note that, using MessageBoxA, you should pay attention to the parameters passed to it, the characters must be single-byte, that is, ASCII, in the program is char, if the use of MessageBoxW, then, Characters must use Unicode, which is wchar_t in the program. But there's a very inconvenient place, and that is, if you use the function of the W suffix series, then your program uses a Unicode character encoding, but if you need to use the source code of this program to compile characters using ASCII-coded programs, then the need to change the place is too large. Any place that involves character manipulation needs to be changed. So, is there a better way to compile an ASCII version of the program with the same code without making changes?
Of course, we are programming when we try to use the macro definition without suffix, as in the example, the use of MessageBox, where the parameters are not explicitly using char or wchar_t but use Microsoft to give us the definition of TCHAR character data type, its definition and above The MessageBox function is defined almost by whether the TCHAR is defined as char or wchar_t based on the definition of Unicode, so that the TCHAR data type is variable, defined as the corresponding final Character type so that our program can easily compile another version without making any changes. is not very convenient.
The first 2 articles of pure text introduction more, because many are conceptual, need to understand, the following article I am ready to cooperate with some small sample programs, using some simple API functions, the related concepts encountered in the method introduced. So, the first 2 articles if your friends are not very understandable, do not worry, the impact is not very large, after the study, you will slowly understand the content of the above.