Chinese garbled characters in English operating system (NVARCHAR and varchar differences in SQL)

varchar uses a single byte to store data in SQL Server, and nvarchar uses Unico to store data.  Chinese characters stored in SQL Server are saved as two bytes (typically with Unico encoding), English characters are saved to the database, and if the field's type is varchar, only one byte is consumed, and two bytes if the field is of type nvarchar. Under normal circumstances, we can also store Chinese characters using varchar, but if the operating system is an English operating system and the support is not comprehensive, the text character in SQL Server store is varchar is garbled (shown as??). And under normal circumstances, the host will support the Chinese environment, so if the use of varchar to store data, in the development phase is not found.  In most cases, there will be no problem at the time of deployment. But! If the host computer is an English operating system and does not support the Chinese environment, then the problem comes out. All varchar fields are garbled when they are stored in Chinese (shown as??). ）． And generally you don't know this because you're using the wrong data type to store the resulting, you'll try to install the Chinese font, try to set the operating system's language environment ... None of this solves the problem, and the only solution is to nvarchar (or nchar) the type of database field.  More familiar with the project management of friends should know, to the deployment stage to modify the database is a very scary thing.  Another good thing about using nvarchar is that you don't need to consider the difference between the two characters when judging a string. Of course, using nvarchar to store English characters will increase storage space by one more times.  But given the low cost of storage, prioritizing compatibility gives you more benefits. Therefore, when design should try to use nvarchar to store data. Use varchar to store only if you are sure that the field is not saved in Chinese. 1, CHAR.     Char is convenient for storing fixed-length data, and the index on a char field is highly efficient, such as defining char (10), which takes up 10 bytes of space regardless of whether the data you store is 10 bytes. 2, VARCHAR. Store variable-length data, but the storage efficiency is no higher than char. If the possible value of a field is not fixed length, we only know that it cannot exceed 10 characters, it is the most advantageous to define it as VARCHAR (10). The actual length of the varchar type is +1 of the actual length of its value. Why "+1"? This byte is used to hold the length that is actually used. From space considerations, with varchar appropriate;With char appropriate, the key is to find a trade-off point based on actual situation. 3, TEXT.     Text stores non-Unicode data of variable length, with a maximum length of 2^31-1 (2,147,483,647) characters. 4, NCHAR, NVARCHAR, NTEXT. These three kinds of names from the first three more than the previous "N". It represents a character stored in a Unicode data type. We know that characters, the English character only need a byte storage is enough, but the number of Chinese characters, need two bytes of storage, English and Chinese characters at the same time prone to confusion, the Unicode character set is to solve the character set this incompatibility problem, all of its characters are expressed in two bytes, That is, the English character is also represented in two bytes. The length of the nchar and nvarchar is between 1 and 4000. Compared to char and varchar, nchar and nvarchar store up to 4,000 characters, whether in English or Chinese characters, while char and varchar can store up to 8,000 English and 4,000 Chinese characters.     It can be seen that the use of nchar, nvarchar data types without worrying about the input characters are English or Chinese characters, more convenient, but in the storage of English number of some losses. So generally, if it contains Chinese characters, use Nchar/nvarchar, if pure English and numbers, with Char/varchar

Garbled characters in the English operating system (NVARCHAR and varchar differences in SQL)