如前文所述，为了让UTF-16能继续编码基本平面后面的增补平面中的码点值，于是扩展了UTF-16编码方式。...在UTF-16编码方式中，引导代理的后面应该是一个尾随代理，而尾随代理的前面就应该是一个引导代理；不能出现一个引导代理的后面是一个非代理的普通UTF-16码元的情况，也不能出现一个引导代理的后面还是一个引导代理的情况...UTF-16文本(字符串)的最后一个码元不能是引导代理，不允许出现一个尾随代理的前面是一个尾随代理的情况，也不允许出现一个尾随代理的前面是一个非代理的普通UTF-16码元的情况；UTF-16文本(字符串...但许多早期的编码方式就不是自同步的，比如大多数的多字节编码标准如GBK、Big5等，必须从头开始分析文本才能确定不同字符的码元的边界；也不具有非传递性，局部字符数据被破坏，很可能传递到整个文件，导致整个文件无法正确显示...因此，虽然编程时同时考虑文本中可能出现的不同存储长度的字符(BMP有效字符是单16位编码，即单码元编码；增补字符是双16位编码，即双码元编码)并相应做出不同的处理，会比单纯只考虑16位编码在性能上要逊色一些
0.一个汉字占多少字节与编码有关： UTF－8：一个汉字＝3个字节 GBK：一个汉字＝2个字节 1.varchar(n)，char(n)表示n个字符...的取值范围为-128~127，占用1个字节（-2的7次方到2的7次方-1） short的取值范围为-32768~32767，占用2个字节（-2的15次方到2的15次方-1） int的取值范围为（-2147483648...~2147483647），占用4个字节（-2的31次方到2的31次方-1） long的取值范围为（-9223372036854774808~9223372036854774807），占用8个字节（-2的...浮点型的数据是不能完全精确的，所以有的时候在计算的时候可能会在小数点最后几位出现浮动，这是正常的。...byte型； boolean t = true； boolean f = false； char型（文本型） 用于存放字符的数据类型，占用2个字节，采用unicode编码，它的前128字节编码与ASCII
，百分号是一个关键字符，这样可以避免在打日志或者其他设计格式化的操作时出现错误。...但是在某些情况下，当对端采用的不是 UTF-8，或者是对端采用的不是网络字节序时（比如对方是技术底下/落后、但却话语权强大的客户/合作商/集成商），这个时候，大家统一采用 ASCII 编码，就能够避免这些问题了...通过这种方式，编码和传输 Unicode 字符。在 ASCII 为主的数据传输中，这种编码方式比较稳妥，并且不会额外增加过多的数据量。...当然对于 Unicode 字符比较多的情况下（比如大量的中文），这就需要程序员考虑一下额外带来的网络花销了。...大于 65535 的字符要怎么表示呢？首先，绝对不是简单地采用 \uXXXXX，这会导致编码错误。 针对大于 65535 的字符，JSON 采用的是 UTF-16 编码。
比如如果中文和日文的不同文字使用了同一个编码值进行表示，那么一篇中文的软件/操作系统中创作的文章，到了日文软件/操作系统中显示就会出现乱码。...而且，由于我们的常用字符大部分只需要2个字节就能表示。所以这些额外的空间在大部分情况下，都是白白“浪费”了。...他选择了 D800-DBFF编码范围作为前两个字节（utf-16高半区），DC00-DFFF作为后两个字节（utf-16低半区），组成一个四个字节表示的字符。...当软件解析到Unicode连续4个字节的前两个是utf-16高半区，后两个是utf-16低半区，他就会把它识别为一个字符。如果配对失败，或者顺序颠倒则不显示。...在可见的未来都不会出现不够使用的情况。 而且代理对区间的编码不能单独映射字符，因此不会产生识别错误。
5 - UTF-16 UTF-16定义了Unicode字符在计算机中的存取方法，UTF-16使用两个字节表示Unicode的转化格式，这是一个定长的表示方法，无论什么字符UTF-16都用两个字节表示...4 - 按照UTF-16编码 字符串“I am 君山”用UTF-16编码时，编码结果如图 用 UTF-16 编码将 char 数组放大了一倍，单字节范围内的字符，在高位补 0 变成两个字节，中文字符也变成两个字节...2）UTF-16与UTF-8都是处理Unicode编码，它们的编码规则不太相同，相对来说，UTF-16的编码效率较高，从字符到到字节的相互转换更简单，进行字符串操作也更好。...这种出现乱码且乱码字符串长度是原编码前字符串的两倍的原因可能是采用2字节编码例如GBK、UTF-16等然后使用单字节进行解码例如ISO-8859-1导致的 2 - 一个汉字变成一个问号 例如，字符串...虽然最终能取得正确的汉字，但是还是不建议用这种不正常的方式取得参数值，因为这中间增加了一次额外的编码与解码，这种情况出现乱码时因为 Tomcat 的配置文件中 useBodyEncodingForURI
这里额外总结一下这四个兼容性关系是GB18030兼容GBK，GBK兼容GB2312，GB2312兼容ASCII。所谓兼容，你可以简单理解为子集、不冲突的关系。...例如GB2312编码的文件中可以出现ASCII字符，GBK编码的文件中可以出现GB2312和ASCII字符，GB18030编码的文件可以出现GBK、GB2312、ASCII字符。...，出现标准不同。...UTF-16和UTF-32也就是如今Unicode编码的标准之二，他们的区别就是UTF-16是变长编码，大部分是2字节和少部分4字节，UTF-32是定长编码，表示任何字符都用 4 字节 （4）UTF-8...在这种情况下，一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语言中文处理又会出现问题，这一情况无法避免。
utf-8 编码最大的特点就是变长编码，它使用 1～4 个字节来表示一个符号，根据符号不同动态变换字节的长度； ucs-2 编码最大的特点就是定长编码，它规定统一使用 2 个字节来表示一个符号； utf...，如果高两位字节不为空就组合成一个四字节 utf-16 编码的字符并返回。...，high 对应的是高位字节，(data[offset++] & 0xff) 则为低位字节，所以我们可以得出结论，String 对象通过这种情况下创建的同样是 utf-16 编码。...我的一个推测是：可能老版本的 Android 系统使用的是 ucs-2 编码，并没有对 BMP 之外的平面集做处理，所以也不存在 4 字节的 utf-8，在扩展为 utf-16 编码之后，自然而然就需要额外对...的 utf-8 编码为 F0A0B296，在线查询网站：Unicode和UTF编码转换），在 Android 4.3 上通过 env->NewStringUTF 的方式转换之后会出现崩溃，在 Android
# Unicode的实现方式 UTF-8 使用一至四个字节为每个字符编码 UTF-16 使用二或四个字节为每个字符编码 UTF-32 使用四个字节为每个字符编码 举个例子:Unicode规定了一个中文字符...当你处理大量文本的时候，使用 32 位整数存储 Unicode 会占用大量额外存储、内存、带宽等。 最常见的是你会看到 Unicode 文本被编码为UTF-8 或 UTF-16。...ASCII 字节不会出现在非 ASCII 编码点中，所以搜索以 NULL 结尾或分隔符结尾的字符串是可以的。 使扩展遗留 ASCII 程序和 API 来处理 UTF-8 字符变得简单。...UTF-16 你可能遇到的另一个编码是 UTF-16，它使用 16-bit 字，每个字符被存储为 1 个或 2 个字节=16bit.和 UTF-8 一样，我们可以用二进制前缀的形式表示 UTF-16 的编码规则...相反，动态组合系统可以让你构造你想要的任何字符，通过以一个基础编码点（字母）开始然后附加额外的编码点，被称作”组合标识”，来指定变音符。
##关于字符编码内容涉及：UTF-8编码UTF-16编码你好UTF8编码：E4 BD A0 E5 A5 BD计算UTF-16编码得到：UTF16编码: 4F 60https://home.unicode.org...后来又出现了4字节编码，即UCS-4UCS在计算机中的存储格式叫做UTF(Unicode Transformation Format)UCS-2最直接的存储格式就是UTF-16了。...由于UCS-2没有定义FFFE， 因此规定只要出现FFFE就是UTF-16LE，出现FEFF就是UTF-16BEUTF-32就简单了，它用四个字节表示字符，这样就可以完全表示UCS-4，而无需像UTF-...，多数在ASCII的范围内，不管使用UTF-16还是UTF-32都会造成很大的浪费因此，又提出了用1～4个字节来表示的UTF-8，方式如下可见，ASCII字符(0000-007F)只使用一个字节，避免了空间的浪费...另外，从表中可以看出，从首字节的取值范围就可以知道编码的字节数，这样大大简化了算法话说，制定标准的这伙儿人呀，智商实在是高待补充UTF-32编码纸上得来终觉浅, 绝知此事要躬行。
UTF-16 用两个字节来表示 Unicode 转化格式，这个是定长的表示方法，不论什么字符都可以用两个字节表示，两个字节是 16 个 bit，所以叫 UTF-16。...用 UTF-16 编码将 char 数组放大了一倍，单字节范围内的字符，在高位补 0 变成两个字节，中文字符也变成两个字节。从 UTF-16 编码规则来看，仅仅将字符的高位和地位进行拆分变成两个字节。...UTF-16 虽然编码效率很高，但是对单字节范围内字符也放大了一倍，这无形也浪费了存储空间，另外 UTF-16 采用顺序编码，不能对单个字符的编码值进行校验，如果中间的一个字符码值损坏，后面的所有码值都将受影响...UTF-16 与 UTF-8 都是处理 Unicode 编码，它们的编码规则不太相同，相对来说 UTF-16 编码效率最高，字符到字节相互转换更简单，进行字符串操作也更好。...虽然最终能取得正确的汉字，但是还是不建议用这种不正常的方式取得参数值，因为这中间增加了一次额外的编码与解码，这种情况出现乱码时因为 Tomcat 的配置文件中 useBodyEncodingForURI
我们常用的编码格式有ASCII，Unicode，UTF-8,GB2312等，如何在这些编码之间安全转换呢？...通常，邮件内容都会经过Base64编码，在邮件接收端，需要对其解码，得到字节流，再进一步解码为正确的字符串，如 Base64.cs文件中： public static class Base64 ...，在英文环境或许没有问题，但如果发信方用的编码格式跟你不一样，这样就会出问题，比如对方是UTF-8编码，而自己的默认编码是GB2312。...另外一种情况就是对于Base64编码的二进制数据，比如邮件中的图片等，原代码的方式更是成问题，我们的Encoding.Default 编码会破坏原始的二进制字节信息，但这些信息又想作为字符串在系统中使用...二进制字节都是8位编码的，只有采用8位编码格式的方案才可以完整保留二进制数据。
那么4个字节的码元就可能存在字节序的问题，例如 000003A9 变换字节序之后可能就变成了： 03A90000 ，这时解码就会出现问题。...UTF-16 UTF-16编码方式是变长字节的，可以看到有的码点只需要2个字节，有的码点需要4个字节。...这种方式下码元是2字节的，每个码点可能由1个码元组成，也可能由2个码元组成，但是不管由几个码元组成，也都会出现字节序的问题。...UTF-16BE====>A A--encode with UTF-16,decode with UTF-16LE====>�䄀 可以看到，用一种编码方式编码出来的结果，用另一种编码方式去解码，就会出现乱码的情况...甚至用相同的编码方式，解码时指定的字节序不同也会出现乱码的情况。 实用工具介绍 我们在处理自定义协议，或者抓包到一段报文时，常常需要进行协议的解析，而这时通常需要进行字符的解码。
强烈建议不要使用操作系统的默认编码，因为这样你的应用程序的编码格式就和运行环境绑定起来了，在跨环境是很可能出现乱码。 内存操作中的乱码 内存中进行字符到字节的转换也很常见。...按照ISO-8859-1编码 ? ISO-8859-1是单字节编码，中文“君山”被转化成值是3f的byte，3f也就是“?”字符。所以经常会出现中文变成“?”...用utf-16编码将char数组放大了一倍，单字节范围内的字符在高位补0变成两个字节，中文字符也变两个字节。 编码效率非常高，规则很简单。 按照utf-8编码 ?...utf-16编码效率最高，字符到字节相互转换更简单，进行字符操作也更好，它适合本地磁盘和内存之间使用，可以进行字符和字节中间的快速切换，java内存编码就采用utf-16编码； 但是UTF-16不适合网络之间的传输...Java Web中涉及的编解码 URL的编解码 浏览器编码URL将非ASCII字符按照某种编码格式编码成16进制数字后在每个16进制表示的字节前加上“%”，所以就出现了如下情况： http://tanqingbo.com
最早最通用的单字节编码系统，因为发明时间早，所以ASCII编码表的设计较为简单。...而unicode的出现直接一次性扫清了所有障碍，原因很简单：unicode编码表中包含了世界上所有国家的所有字符和符号的编码。...6 UTF-16 UTF-16不是简单的把UTF-8的范围扩大了一倍，UTF-16和UTF-8是彻底不同的两种编码概念。...结构 在绝大多数情况下，UTF-16中一个字符固定使用两个字节编码，一个字符两个字节是UTF-16编码的概念。 在极少数情况下也会出现三个字节表示一个字符的情况。...UTF-16容错情况比UTF-8好，因为UTF-16稳定使用两个字节编码，如果数据错误不会连代其他数据被读错，而UTF-8是变长编码，可能导致后面的字符全部错误。
由于UTF-16对于ASCII字符也必须使用两个字节(因为是16位码元)进行编码，存储和处理效率相对低下，并且由于ASCII字符经过UTF-16编码后得到的两个字节，高字节始终是0x00，很多C语言的函数都将此字节视为字符串末尾从而导致无法正确解析文本...并且，0x00~0x7F不会出现在UTF-8编码的非ASCII字符的首字节与非首字节的任意一个字节中(非ASCII字符的UTF-8编码为由多个单字节码元所组成的码元序列)，这样就保证了与早已应用广泛且已成为工业标准的...UTF-8同其他的多字节码元编码方式相比具有以下优点： a) UTF-8的编码空间足够大，未来Unicode新标准收录更多字符，UTF-8也能适应，因此不会再出现UTF-16那样的尴尬。...最初，字符U+FEFF如果出现在字节流的开头，则用来标识该字节流的字节序——是高位在前还是低位在前；如果它出现在字节流的中间，则表达为该字符的原义——零宽度不中断空格(ZERO WIDTH NO-BREAK...从Unicode 3.2开始，U+FEFF只能出现在字节流的开头，且只能用于标识字节序，就如它的别名——字节序标记——所表示的意思一样；除此以外的用法已被舍弃。
GB2312覆盖了汉字的大部分使用率，但不能处理像古汉语等特殊的罕用字，所以后来出现了像GBK、GB18030这种编码。...GBK是向下兼容GB2312编码的，也就是说GB2312编码的汉字可以用GBK正常解码不会出现乱码，但用GBK编码的汉字用GB2312解码就不一定了。...UTF-16 UTF-16是UNICODE的具体实现，16即16位，UTF-16即是这个来由，定义了UNICODE字符在计算机中的存储方式，UTF-16同样使用了两个字节来表示任何字符，这样使得操作字符串非常高效...UTF-16适合在磁盘与内存之间使用，字符和字节的相互转换会更加简单和高效，但不适合在网络上传输，因为网络传输可能会损坏字节流。...UTF-8 虽然UTF-16很高效，但也是UNICODE最大的坏处，使得所有单字节字符一定要占两个字节，存储空间放大了一倍，这明显消耗了资源，不符合现在互联网高速发展的现状。
： 首先，是将一个固定字符串“aaaaaa”与你的QQ号和密码这三组字符串，以制表符（’\t’）相连，拼成一个新的字符串，并将其转为UTF-16编码 ?...然后，将上面的拼出的字符串的字符数（非字节数，实际上由于是UTF-16编码，字符数是字节数的1/2），保存为大端的WORD形式 ?...接着，再将之前得到的账号信息字符串取Hex字符串后再次进行UTF-16编码…… 我自己说着都乱……举个例子，字符’a'，也就是’\x61′，UTF-16编码后就是’\x61\x00′，取Hex字符串就变成了...同时，前面获取到的字符数也做同样的处理，并拼到上面这个字符串的前面，如下： ? 最后，以16字符为一批进行循环加密，并将加密后数据转成UTF-16编码的Hex字符串，最终结果如下： ?...一个DNS查询而已，没有额外的非法数据，只是查询了一个不存在的域名，伪装的够深了吧！ 百密一疏 但其实，通过Wireshark抓包还是可以看到一个很讽刺的事实——这个数据包依然是畸形的！
每个国家或地区都有自己的一套编码方案，于是当信息在国际间间流是就会出现乱码问题，好比世界上每个国家都有自己的语言，相互交流时就会出现障碍。...Unicode和UCS虽然对全球字符编码的码值相同，ISO/IEC 10646标准，就像ISO/IEC 8859标准一样，只不过是一个简单的字符集表，但Unicode标准，额外定义了许多与字符有关的语义符号学...但是与UTF-8的区别主要有UTF-16最短编码长度是2个字节，UTF-8最短是1个字节，还有就是UTF-8不存在字节序的问题，UTF-16存在字节序的问题。...UTF-16比起UTF-8，好处在于大部分字符都以固定长度的字节（2字节）存储，但UTF-16却无法兼容于ASCII编码，因UTF-8兼容 ASCII，能适应许多 C 库中的 ‘\0’结尾惯例，没有字节序问题...单字节编码如ASCII是不存在编码字节序问题的，每一个字节代表一个字符，但是对于Unicode多字节字符编码，如UTF-16和UTF-32，就会存在字节序的问题。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
云直播
