关于编码
什么是编码
计算机是处理二进制的机器，自出现一来人们一直在优化着人与机器间的交互方式。(→_→) 一切都是因为二进制的01010看起来太反人类了。
密密麻麻的出现时，简直是灾难。所以汇编语言出现了，大家不用二进制的方式编码了，写出来的东西也没那么难看懂了。再后来更高级的语言，FORTRAN，C
出现了。本质上无论是何种语言编写的程序，最后都会以二进制形式运行于内存之中。所以，从广义上来说编程语言是二进制机器语言的一个“编码集”。
(:з)∠) 可以用同样的方式来理解文本编码，所谓的编码，本质上是定义二进制语言的字典。据我所知，最早的编码集是1963年publish的ASCII，他主要处理的问题是，定义一个二进制映射到字符的表。比如说二进制的100 0001表示字符A。然而ACSII编码只用了一个bytes的空间，一bytes有8个bits，最多只能表示256个字符，自然没法囊括文明世界的全部语言。后来，就出现了各种编码集来兼容不同的语言。
Unicode
这些编码集的出现没有完全解决问题，反而使问题变得更复杂。因为他们互不兼容，没法统一。这个时候Unicode就出现了（及UCS）。
Unicode（中文：万国码、国际码、统一码、单一码）是计算机科学领域里的一项业界标准。它对世界上大部分的文字系统进行了整理、编码，使得电脑可以用更为简单的方式来呈现和处理文字。
然而Unicode跟ASCII等编码集是有本质区别的，Unicode是一项标准，是符号集。如果Unicode也以ASCII编码集同样的思路来解决问题，必定还会出现不兼容的问题。所以他并不是直接定义二进制到字符的字典的。他引入了一个新的概念，code point。他定义的是字符到code point的映射关系，也就是说，他给编码集做了一个中间层。这样所有编码集最后只需要映射到code point就可以了，映射到什么字符不用关系，如此一来就可以使编码不兼容的问题得到解决。当然Unicode实现的机制并没有这么简单，能力有限就不过多涉及了~
UTF-8，UTF-16等都是基于Unicode的，不同之处在于他们表示Unicode code point的方式。
UTF-8
Unicode标准成立之后，UTF-8之所以能够流行起来。在于UTF-8是一种可变长的编码集，并且最重要的一点是，他完全兼容ASCII码。
像UTF-16虽然他也是基于Unicode的，但他是用两个bytes的定长来编码的。耗费的空间更多，而且不兼容ASCII码。很多老语言的编码是ASCII码的，比如说c，所以向后兼容的当然会更受欢迎。
UTF-8是采用8bit的长度进行编码，当无法容纳code point的范围时，可以扩展长度来表示。Unicode编码里汉字对应的code point编码范围为4E00-9FFF，
用UTF-8来表示的话需要2-3个bytes，而用UTF-16的话为2bytes。在这种情况，如果一个文本里只有中文并且很长的话，用UTF-16反而会更节省空间。但需要兼容不同语言时，UTF-8就显得更省空间了。
编码失真
当一个文件以某种形式编码时，你必须以这种编码方式打开时，才有可能正确显示。
如果一个文件以UTF-8形式编码，而你尝试以ASCII编码打开，那么就会出现失真。
因为ASCII码，最多只能显示258种字符，不能显示的部分有可能被替换成Unicode的占位符� (U+FFFD)
那么你的文档就再也不能被复原回原来的样子。
但如果你的文档原来是以ASCII存储，你用UTF-8或ISO-8859-1等兼容ASCII码的编码打开。
则不会出现失真，只需要切换回ASCII编码，文档就可以正常显示。但用UTF-16打开就会出现
失真。道理是一样的。
URL编码
URL编码也称为 百分号编码。
"...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL."
"只有字母和数字[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字，才可以不经过编码直接用于URL。"
所有浏览器上非以上字母的都会编码。任何字符只要不是ASCII码数字，字母，或者前面提到的标点符，它们都将被转换成字节形式，每个字节都写成这种形式：一个“%”后面跟着两位16进制的数值。空格是一个特殊情况，因为它们太平常了。它除了被编码成“%20”以外，还能编码为一个“+”。加号（+）本身被编码为%2B。当/ # = & 和?作为名字的一部分来使用时，而不是作为URL部分之间的分隔符来使用时，它们都应该被编码。
同样，当content-type为application/x-www-form-urlencoded时，也会对非符合字符进行编码。
javascript encoding
关于Javascript的默认编码问题，翻了不少文章，并未能理清思路。
贴出一些有用的资料，留作以后再翻看。
A conforming implementation of this International standard shall interpret characters in conformance with the Unicode Standard, Version 3.0 or later and ISO/IEC 10646-1 with either UCS-2 or UTF-16 as the adopted encoding form, implementation level 3. If the adopted ISO/IEC 10646-1 subset is not otherwise specified, it is presumed to be the BMP subset, collection 300. If the adopted encoding form is not otherwise specified, it is presumed to be the UTF-16 encoding form.
In other words, JavaScript engines are allowed to use either UCS-2 or UTF-16.
