1. bit：位
    一个二进制数据0或1，是1bit；

2. byte：字节
    存储空间的基本计量单位，如：MySQL中定义 VARCHAR(45)  即是指 45个字节；
    1 byte = 8 bit

3. 一个英文字符占一个字节；
    1 字母 = 1 byte = 8 bit

4. 一个汉字占2个字节；
    1 汉字 = 2 byte = 16 bit




java字符串(String)就是Unicode字符序列。

JAVA的String只使用2byte表示一个字符

String字符串里面 一个字符2字节 


求字符串占多少字节， 比如
String str = "abc";
str 有三个字符 占6个字节



c++ 字符串有4种类型：

1,typedef basic_string<char> string;

char的大小是1个字节。

string 一个字符占一个字节  而且string有一个字符表示结尾 这个字符不会被length计算 所以length+1就是所占字节 sizeof出来的数字是默认开的空间 也就是只要定义一个string 系统就会为它分配32字节。


2，typedef basic_string<wchar_t> wstring;   

wchar_t 在windows上大小是2个字节， 在linux下是4个字节，一个字符占了4个byte，与Java的String不一样。


3，typedef basic_string<char16_t> u16string; 

sizeof(char16_t)=2,无论什么平台， char16_t占两个字节。


4，typedef basic_string<char32_t> u32string; 

sizeof(char32_t)=4,无论什么平台， char32_t占4个字节。


在sizeof(wchar_t)=4的系统，wstring与u32string是一样的，在sizeof(wchar_t)=2的系统，wstring与u16string是一样的。





那要与Java的两个字节表示一个字符的String一样，是不是可以用u16string呢，是的。


如果不支持c11,当然也可以自定义一个两个字节表示一个字符的类型，已达到与Java的String一致：

关于char_traits的编写参见：http://zh.cppreference.com/w/cpp/string/char_traits

typedef std::basic_string<twchar, twchar_traits>	twstring;
typedef unsigned short				twchar; //肯定是两个字符。
class twchar_traits 
{
public:
	typedef twchar char_type;
	typedef int int_type;
	static void assign(char_type& __c1, const char_type& __c2) { __c1 = __c2; }
	static bool eq(const twchar& __c1, const twchar& __c2) 
		{ return __c1 == __c2; }
	static bool lt(const twchar& __c1, const twchar& __c2) 
		{ return __c1 < __c2; }

	static int compare(const twchar* __s1, const twchar* __s2, size_t __n) {
		for (size_t __i = 0; __i < __n; ++__i)
		if (!eq(__s1[__i], __s2[__i]))
			return __s1[__i] < __s2[__i] ? -1 : 1;
		return 0;
	}

	static size_t length(const twchar* __s) {
		const twchar __nullchar = twchar();
		size_t __i;
		for (__i = 0; !eq(__s[__i], __nullchar); ++__i)	{}
		return __i;
	}

	static const twchar* find(const twchar* __s, size_t __n, const twchar& __c) {
		for ( ; __n > 0 ; ++__s, --__n)
			if (eq(*__s, __c))
				return __s;
		return 0;
	}

	static twchar* move(twchar* __s1, const twchar* __s2, size_t __n) {
		memmove(__s1, __s2, __n * sizeof(twchar));
		return __s1;
	}
    
	static twchar* copy(twchar* __s1, const twchar* __s2, size_t __n) {
		memcpy(__s1, __s2, __n * sizeof(twchar));
		return __s1;
	} 

	static twchar* assign(twchar* __s, size_t __n, twchar __c) {
		for (size_t __i = 0; __i < __n; ++__i)
			__s[__i] = __c;
		return __s;
	}

	static int_type not_eof(const int_type& __c) {
		return !eq_int_type(__c, eof()) ? __c : 0;
	}

	static char_type to_char_type(const int_type& __c) {
		return static_cast<char_type>(__c);
	}

	static int_type to_int_type(const char_type& __c) {
		return static_cast<int_type>(__c);
	}

	static bool eq_int_type(const int_type& __c1, const int_type& __c2) {
		return __c1 == __c2;
	}

	static int_type eof() {
		return static_cast<int_type>(-1);
	}
};




参考网页:

http://stackoverflow.com/questions/14438129/stdstring-wstring-u16-32string-clarification 也有人如此问答:

My current understanding of the difference between std::string and std::wstring is simply the buffer's type; namely, char vs wchar_t, respectively.

I've also read that most (if not all) linux distros use char for any and all strings, both ASCII as well as UTF, where Windows is the primary OS that uses wchar_t anymore.

However, there are a few more string types that I want to get straight in my head: u16string and u32string, which are strings with 2-byte and 4-byte buffers, respectively.

So, my question is this:

On platforms with sizeof(wchar_t) == 2, is std::wstring functionally equivalent to std::u16string, as well as platforms with sizeof(wchar_t) == 4 and std::u32string?


The difference is that the details of char and wchar_t are implementation defined, while the encoding of char16_t and char32_t are explicitly defined by the C++11 standard.

This means that wstring is likely to be the same as either u16string or u32string, but we don't know which one. And it is allowed for some odd implementation to make them all different, as the size and encoding of the old char types are just not defined by the standard.