文字编码总结
做一个试验。
新建一个文本文件，然后用记事本打开，输入“联通”，保存，关闭。
再次用记事本打开这个文本文件，你看到了什么？
这被人戏称是联通干不过移动的根本原因——连自己的名字都存不下来。
下面对字符的编码进行一下总结，会在其中说明联通消失的原因。
ASCII = American Standard Code for Information Interchange， “美国信息交换标准码”
ASCII码规定每个字符例使用1个字节来表示，也就是8位的二进制组合，那么就有00000000-11111111一共256种组合，也就是可以表示256个不同的字符。
但是实际上ASCII共计有128个，从0到127，也就是从00000000-01111111，最高位都是0。
目的：解决汉字等英文字母以外字符的显示问题。
基本方法：使用最高位是1的字符（防止与ASCII冲突），2个字节表示一个汉字。
编码转换方法举例：
这些使用 2 个字节来代表一个字符的各种文字延伸编码方式，称为 ANSI 编码。
注意ANSI编码指是“本地化”编码，在各个国家对应的编码体系是不同的。
在中文环境下以ANSI编码存储的文件，在日文环境下打开是乱码。因为一个是GB2312编码，一个是JIS编码。
（顺便吐槽，有个国标组织是很幸福的事情，日本通用的编码方式至少有四套，特么的两个公司做的系统之间通信，弄的跟国际化似的还要转换编码，比如：神奇的みずほ银行）
为了使国际间信息交流更加方便，国际组织制定了unicode字符集。
为各种语言中的每一个字符设定了统一并且唯一的数字编号，以满足跨语言、跨平台进行文本转换、处理的要求。
unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符。
unicode编码中，不管什么文字统一使用4字节表示一个文字。
unicode中，每个字符用 4 个字节在存储、传输时会产生浪费。
UTF-8、UTF-16、UTF-32都是unicode的“紧凑”编码。都是 可变长度 编码。（所以想一下java中计算字符串长度时，碰到汉字的时候得到的到底是什么的长度？）
UTF = Unicode Transformation Format。
其中UTF-32使用32位整数编码，还是占4个字节（32bit），所以基本上不会使用。
UTF-8或UTF-16，分别由 8-bit 或 16-bit 为一个单元组成，下标值较小的编码点占用的字节数也少。
utf-8 使用 1~4 个不等的字节来存储字符编码。
以“郑”字为例，说明从unicode到utf-8的转换。
UTF-8 有一个方便的属性，即最开始128 个字符（ASCII字符）被编码为单个字节。
使用 NotePad++ 这样的文本编辑器时，可以将文件“以 UTF-8 无 BOM 格式编码”。
所谓的BOM，全称是Byte order mark。
作用是在文件最开始加入一个标识符，让文本编辑器明确知道读入的文件是以何种方式编码的。
常用的BOM如下：
记事本默认的编码是 ANSI，对于中文系统中就是 GBK 编码。
“联”字的编码是 0xc1aa，二进制 110 0 0001 10 10 1010。
“通”字的编码是 0xcda8，二进制 110 0 1101 10 10 1000
→ 这玩意跟编码规则中第二行是相符的。
所以记事本再次打开这个文件的时候，将其识别成了“UTF-8 无 BOM 格式”，所以全程按照utf-8编码规则解析，就变成了乱码。
人家移动俩字就没这事。电信啥的也都没事。
结论：当文档中的所有字符的二进制编码在C0≤AA(第一个字节)≤DF 80≤BB(第二个字节)≤BF时，记事本都无法确认文本的编码格式，就按照UTF-8的格式来显示。
在第一章提到的第三个阶段（国际化）的初期，其实有两套国际化编码。
UCS-2 是 ISO 10646标准为“通用字符集”（UCS）定义的16位 固定长度 编码。
它包含65536个编码空间，存储的是全世界最常用的65536个字符编码。
可以认为 UCS-2 是 UTF-16 的一个子集，编码相同。其实UCS-2就是原始的双字节Unicode编码。
UCS-2 这种两字节定长编码，在存储的时候，有两种格式。
参看 Notepad++ 的编码菜单，里面有“以 UCS-2 Little endian 格式编码”以及“以 UCS-2 Big endian 格式编码”
比如“郑”的编码是 90D1 （没错，对于这个字的编码，unicode、ucs-2和utf-16是相同的）
如果存储为 90D1，叫做BE（Big endian）；倒过来存为 D190 的话，称为LE（Little endian）。
习惯windows系统的人可能根本没见过LE，但是在Unix/Linux中这种情况并不少见。
在 UCS-2/unicode（兼容） 编码标准中，规定在每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做"零宽度非换行空格"（zero width no-break space）。
→ 等等，文件头上的信息不是BOM吗？
完整的BOM编码
也就是说，表达编码种类以及BE、LE的工作都是由BOM来完成的
其实Linux默认UTF-8编码应该不带BOM的。
尽管 Unicode 标准允许在 UTF-8 中使用 BOM，但不含 BOM 的 UTF-8 才是标准形式，在 UTF-8 文件中放置 BOM 主要是微软的习惯。
因为把带有BOM的小端（LE）的 UTF-16 称作「Unicode」也是微软的习惯
猜（参看联通事件）
mysql支持的 utf8 编码最大字符长度为3字节，而标准的utf-8最大字符长度为4字节。
三个字节的 UTF-8 最大能编码的 Unicode 字符是 0xffff，也就是 Unicode 中所谓的“基本多文种平面（BMP）”。能够应对绝大多数应用场景。
（MySQL刚开发的时候，unicode本身也没有提出“辅助平面”，所以3字节的设计是无可厚非的）
但是包括 Emoji 表情、一些特殊汉字在内的字符是无法存储的。
MySQL 5.5.3 版本以后，推出utf8mb4字符集，用来对应标准的utf-8。
可以参看这篇文章中的“Unicode 介绍”一节
Unicode 及编码方式概述
简单来说，就是把所有字符统一转换成可见字符。
Base64是一种基于64个可打印字符来表示二进制数据的表示方法。
（ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/）
Base64常用于在通常处理文本数据的场合，表示、传输、存储一些二进制数据，包括MIME的电子邮件及XML的一些复杂数据。
由于 2的6次幂=64，所以Base64编码中，以6个比特为一个单元，对应某个可打印字符。
比如，3个字节一共24比特，那么就对应4个Base64单元。
也就是说，编码后的数据长度为原来的 4/3。
若原数据长度不是3的倍数时且剩下1个输入数据，则在编码结果后加2个=；若剩下2个输入数据，则在编码结果后加1个=。
举例：
如果要编码的字节数不能被3整除，最后会多出1个或2个字节，那么可以使用下面的方法进行处理：先使用0字节值在末尾补足，使其能够被3整除，然后再进行Base64的编码。在编码后的Base64文本后加上一个或两个=号，代表补足的字节数。也就是说，当最后剩余两个八位字节（2个byte）时，最后一个6位的Base64字节块有四位是0值，最后附加上两个等号；如果最后剩余一个八位字节（1个byte）时，最后一个6位的base字节块有两位是0值，最后附加一个等号。
UTF-7是一个修改版Base64（Modified Base64）。
主要是将UTF-16的数据，用Base64的方法编码为可打印的ASCII字符序列。目的是传输Unicode数据。
主要的区别在于不用等号=补余，因为该字符通常需要大量的转译。
URL编码(URL encoding)，也称作百分号编码(Percent-encoding)。
适用于统一资源标识符(URI)的编码，也用于为"application/x-www-form-urlencoded" MIME准备数据。
将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式。
举例1：
空格ASCII码是32，对应16进制是20，那么urlencode编码结果是:%20,但在最新标准（RFC-1738）中空格对应的是+。
举例2：
“中”的GB2312码是0xD6D0，那么urlencode编码结果是:%D6%D0
绛旓細鎬荤粨锛氬唴鐮侊細缂栫爜鐨勬牳蹇冿紝纭繚姹夊瓧鐨勭粺涓鎬э紱澶栫爜/杈撳叆鐮侊細杈撳叆鍙嬪ソ锛屾弧瓒虫棩甯镐娇鐢ㄩ渶姹锛涘瓧褰㈢爜/杈撳嚭鐮侊細鐢ㄤ簬灞忓箷涓婃竻鏅板憟鐜帮紝鏄瑙夊憟鐜扮殑鍏抽敭锛汚SCII鐮佸垯鏃犻渶杈撳叆鐮侊紝涓庣幇浠ｆ眽瀛楃紪鐮佷綋绯诲舰鎴愬姣斻傞氳繃GB绯诲垪缂栫爜锛屾垜浠簡瑙ｄ簡鍖轰綅鐮併佸浗鏍囩爜鍜屾満鍐呯爜涔嬮棿鐨勮浆鎹㈤昏緫銆傜户缁垜浠殑缂栫爜鎺㈢储涔嬫梾锛屼笅涓绔犳垜浠皢...
绛旓細缂栫爜鏍煎紡澶浜嗭紝杩欓噷灏介噺鐨勪粙缁嶄笅鍚勭甯歌鐨勭紪鐮佹牸寮忋傚彟澶栵紝鍥犱负璁稿璧勬枡鏄垜鑷繁涓婄綉鏌ョ殑锛屼篃鏈夎嚜宸辩殑鎬荤粨锛屾墍浠ヤ笉涓瀹氭纭紝濡傛灉鍙戠幇鏈夐敊璇紝楹荤儲鎸囧嚭锛屾垜浼氫慨鏀圭殑銆備竴.ANSI 杩欓噷锛屾垜灏咥NSI浣滀负涓涓ぇ椤广傛牴鎹垜鑷繁鐨勭悊瑙ｏ紝ANSI骞朵笉鏄竴绉嶅叿浣撶殑缂栫爜锛岃屾槸涓绉瀛楃浠ｇ爜銆傛瘮濡傦細ASCII銆丟B2312銆丟BK銆丟B...
绛旓細缁撹:褰撴枃妗ｄ腑鐨勬墍鏈瀛楃鐨勪簩杩涘埗缂栫爜鍦–0鈮A(绗竴涓瓧鑺)鈮F 80鈮B(绗簩涓瓧鑺)鈮F鏃,璁颁簨鏈兘鏃犳硶纭鏂囨湰鐨勭紪鐮佹牸寮,灏辨寜鐓TF-8鐨勬牸寮忔潵鏄剧ず銆 鍦ㄧ涓绔犳彁鍒扮殑绗笁涓樁娈(鍥介檯鍖)鐨勫垵鏈,鍏跺疄鏈変袱濂楀浗闄呭寲缂栫爜銆 UCS-2 鏄 ISO 10646鏍囧噯涓衡滈氱敤瀛楃闆嗏(UCS)瀹氫箟鐨16浣 鍥哄畾闀垮害 缂栫爜銆 瀹冨寘...
绛旓細鎬荤粨锛氭枃鏈紪鐮佹槸灏嗘枃鏈暟鎹浆鍖栦负鏁板瓧搴忓垪鐨勮繃绋锛屽彲浠ヤ娇寰楄绠楁満鍦ㄤ笉鍚岀殑鎿嶄綔绯荤粺鍜岀▼搴忎箣闂存纭湴鏄剧ず鍜屽鐞嗘枃瀛椾俊鎭備笉鍚岀殑鍥藉銆佷笉鍚岀殑鍦板尯銆佷笉鍚岀殑璇█銆佷笉鍚岀殑鏂囧寲鑳屾櫙閮介渶瑕佷娇鐢ㄤ笉鍚岀殑瀛楃缂栫爜鏂瑰紡锛屼互渚胯绠楁満鍙互姝ｇ‘鍦板鐞嗗苟鏄剧ず鍑烘暟鎹俊鎭傛枃鏈紪鐮佹槸鐜颁唬璁＄畻鏈洪鍩熶腑闈炲父鍏抽敭鍜屽繀瑕佺殑鎶鏈箣涓銆
绛旓細鎬荤粨涓涓:涓浗鍥藉鏍囧噯鎬诲眬鎶婁腑鏂囧父鐢ㄥ瓧绗︾紪鐮佷负94涓尯锛屾瘡涓尯瀵瑰簲94涓綅锛屾瘡涓瓧绗︾殑鍖哄彿鍜屼綅鍙风粍鍚堣捣鏉ュ氨鏄瀛楃鐨勫尯浣嶇爜, 鍖轰綅鐮佺敤10杩涘埗鏁版潵琛ㄧず锛屽4907灏辫〃绀49鍖7浣嶏紝瀵瑰簲鐨勫瓧绗︽槸鈥滃鈥濄 鐢变簬鍖轰綅鐮佺殑鍙栧艰寖鍥翠笌閫氫俊浣跨敤鐨勬帶鍒剁爜锛00H~1FH锛夛紙鍗0~31锛夊彂鐢熷啿绐併傛瘡涓眽瀛楃殑鍖哄彿鍜屼綅鍙...
绛旓細UTF-8 缂栫爜鏄竴绉嶅父鐢ㄧ殑 Unicode 瀛楃缂栫爜鏂瑰紡锛屽畠浣跨敤鍙橀暱瀛楄妭瀵瑰瓧绗﹁繘琛岀紪鐮侊紝鑳藉琛ㄧず鍑犱箮鎵鏈夌殑瀛楃銆侴BK 缂栫爜鏄竴绉嶇敤浜姹夊瓧缂栫爜鐨勫瓧绗﹂泦锛屽彧鑳借〃绀轰腑鏂囧瓧绗︺侾ython 3.x 榛樿浣跨敤 UTF-8 缂栫爜锛屽洜姝ゅ湪璇诲彇鏂囦欢鎴栬繘琛岀綉缁滀紶杈撴椂锛岄渶瑕佹槑纭寚瀹氱紪鐮佹柟寮忎互閬垮厤鍑虹幇涔辩爜绛夐棶棰樸鎬荤粨鐢变簬瀛楃缂栫爜鍗佸垎澶嶆潅锛...
绛旓細姹夊瓧鐨勫瓧褰㈢爜鍙堢О涓哄涓嬶細姹夊瓧鐨勫瓧褰㈢爜鍙堢О涓姹夊瓧缂栫爜锛圕hineseCharacterCode锛夛紝鏄寚灏嗘眽瀛楄浆鎹㈡垚璁＄畻鏈哄彲澶勭悊鐨勪簩杩涘埗缂栫爜褰㈠紡銆傚畠鏄绠楁満澶勭悊姹夊瓧鐨勫熀纭锛屼篃鏄眽瀛椾俊鎭鐞嗙殑閲嶈鎶鏈箣涓銆
绛旓細锛2锛姹夊瓧缂栫爜 a.姹夊瓧浜ゆ崲鐮侊細涓鑸敤杩炵画鐨勪袱涓瓧鑺傦紙16 涓簩杩涘埗浣嶏級鏉ヨ〃绀轰竴涓眽瀛椼1980 骞达紝鎴戝浗棰佸竷浜 绗竴涓眽瀛楃紪鐮佸瓧绗﹂泦鏍囧噯锛屽嵆 GB2312-80銆婁俊鎭氦鎹㈢敤姹夊瓧缂栫爜瀛楃闆嗗熀鏈泦銆嬶紝璇ユ爣鍑嗙紪鐮佺畝绉板浗鏍囩爜锛屾槸鎴戝浗澶ч檰鍦板尯鍙婃柊鍔犲潯绛夋捣澶栧崕璇尯閫氱敤鐨勬眽瀛椾氦鎹㈢爜銆侴B2312-80 鏀跺綍浜 6763 涓眽瀛...
绛旓細鍙互杈撳叆鏁板瓧鍜姹夊瓧鐨勬鍒欒〃杈惧紡:^[0-9\u4e00-\u9fa5]{2,20}$灏辨槸if(!names.match(/^[\u4e00-\u9fa5]{2,20}$/))鏀规垚if (!names.match(/^[0-9\u4e00-\u9fa5]{2,20}$/))涓嬭〃鎬荤粨浜缂栫爜瑙勫垯锛屽瓧姣峹琛ㄧず鍙敤缂栫爜鐨勪綅銆俇nicode绗﹀彿鑼冨洿 | UTF-8缂栫爜鏂瑰紡 (鍗佸叚杩涘埗) | 锛堜簩杩涘埗锛...
绛旓細涓嬭〃鎬荤粨浜缂栫爜瑙勫垯锛屽瓧姣 x 琛ㄧず鍙敤浜庣紪鐮佺殑浣嶏細璺熸嵁涓婅〃锛岃В璇 UTF-8 缂栫爜涔熼潪甯哥畝鍗曪細濡傛灉涓涓瓧鑺傜殑绗竴浣嶆槸 0 锛屽垯杩欎釜瀛楄妭鍗曠嫭灏辨槸涓涓瀛楃锛涘鏋滅涓浣嶆槸 1 锛屽垯杩炵画鏈夊灏戜釜 1 锛屽氨琛ㄧず褰撳墠瀛楃鍗犵敤澶氬皯涓瓧鑺傘備笅闈紝鎴戜滑灏辨潵婕旂ず涓涓 UTF-8 缂栫爜鐨勮繃绋嬨傞鍏堬紝鑾峰彇姹夊瓧 楸 ...
