乙個位元(bit)可以是0，或者是1，8個位元(bit)，組成乙個位元組(byte)。全為0時代表數字0，全為1時代表數字255。
乙個位元組可以表示256個數字，兩個位元組可以表示65536個數字。
更多的位元組，可以有更多的組合，就可以表示更大的數值範圍。
整數可以這麼存，那字元呢？一堆二進位制的0和1，怎麼也算不出字母a吧。不能直接表示，那就通過數字中轉一下。只要給它指定乙個數值編號，要儲存字元時，就儲存這個數值。要讀取時，按照對映關係找到這個字元。
像這樣收錄許多字元然後給它們一一編號，得到乙個字元編號對照表，這就是「字符集」。
ascii字符集只收錄了128個字元，其擴充套件字符集也只有256個。(ascii最初被設計的目的也只是用來對映英文體系所需要的字元)
這在只使用英文的國家貌似沒什麼問題，但是隨著世界的互聯，其它非英語母語的國家該怎麼辦呢？比如漢字、日文等。
針對漢字，最先設計了gb2312字符集、但是gb2312不包含繁體字，所以又設計了big5字符集，但是依然有很多字元沒有被收錄，其它國家的字型也不在其中
與其不斷推出收錄更多字元的字符集，還不如本著全球化統一標準的目的，製作乙個通用字符集，unicode學術學會就是這樣做的，這個字符集就是unicode，它於2023年開始研發並於2023年正式公布，實現了跨語言跨平台的文字轉換與處理，字符集促成了字元與二進位制的合作。但是有了字符集就萬事大吉了嗎？那怎麼儲存(eggo世界)這個內容呢？
直接的想法是，找到每個字元對應的編號，存成二進位制，如果使用unicode字符集，拿到他們的編號，直接組合會得到這樣一大串二進位制位
問題出現了，該怎麼知道這一長串內容是要按照下面的方式劃分的呢？
也可以按照下面的方式劃分呀
所以，照搬編號的方式，行不通！！！
那現在我們可以知道了，編碼完成之後還需要解決的乙個問題是如何劃分字元邊界。
其中乙個方法可以這樣，不管編號多大多小，統一按照最長的編碼的來，位數不夠的高位補0嘛
這就是定長編碼，這樣就可以解決字元邊界的問題，但是可以發現，這樣就太浪費記憶體了，而且字符集收錄的符號越多，編號跨度就越大，定長編碼造成的浪費就越顯著，還得再想辦法，定長編碼不行，那就「變長編碼」，小編號少佔位元組，大編號多佔位元組。
但是怎麼劃分字元邊界呢？來看一種解決方案，如果編號屬於[0,127]，就占用乙個位元組，且最高位固定標識為0。如果屬於[128,2047]，就占用兩個位元組，且有固定標識位110和10，三個以及更多位元組的編碼也遵循這樣的規則
以二進位制數字01100101，這個位元組最高位是零，就表示這個字元只佔乙個位元組，除去標識位，剩下的7位就是該字元的二進位制編號，轉換成十進位制就是101，對應字元e，「世」字同理。
這樣劃分字元就不成問題了。剛剛我們做的是解碼，現在來編碼試試，世界的「界」字在unicode字符集中編號為30028，符合區間[2048,65535]，所以要占用三位元組，使用下面這個模板。
然後將編號30028轉換成二進位制01110101 01001100，再對應填到模板中
好的，這樣就編碼完成了， 我們剛剛用的其實就是utf-8編碼，也就是go語言預設的編碼方式。
字符集與編碼
前言 今天notepad 檢視測試傳過來的乙個log，開啟後竟然有部分亂碼，無法檢視完整資訊，嘗試更改編碼後仍未能解決，同事告知使用瀏覽器開啟或許可以，於是搗鼓一下，使用瀏覽器開啟並選擇編碼unicode utf 8 後終於正常顯示，順利解決問題。亂碼顯示的問題以前也經常遇到，從未認真對待過，剛好稱...
字符集與編碼
這些東西是自己在知乎上看的，摘抄下來，以便以後查閱，主要內容有 字符集與編碼 byte order mark等。在windows中經常需要用到多字元與寬字元的轉換方法，多字元 multichar 也就是ansi編碼的方式，而寬字元 widechar 也就是unicode編碼的方式。ansi是預設的編...
字符集與字元編碼
字符集 字符集是各種文字和符號的總稱，也就是多個字元的集合，而常見的字符集有 ascii字符集 iso 8859字符集 gb 2312字符集 big 5字符集 gbi 8030字符集 unicode字符集等。計算機要能夠識別和儲存各種字元，就要對各種字符集進行字元編碼。字元編碼 編碼和字符集不同，字...