摘要: 理解計算機是如何存儲數據的。git
Fundebug經受權轉載,版權歸原做者全部。github
PS:數據傳輸大多以 bit 爲單位,好比咱們常說的網速100M/s,M/s其實Mbit/s,也就是兆比特每秒,咱們還能夠寫成100Mbps。編程
ASCII:小程序
/ˈæski/
,即 American Standard Code for Information Interchange,美國信息交換標準代碼。原本一個字節有8位,每一位有0和1兩種狀態,則一個字節共有2^8=256種狀態,能夠表示256種字符。可是美國佬比較自私,以爲只要能夠表示本身的字母和一些特殊字符就足夠了,因此 ASCII 沒有佔用最高位(而是固定爲0),實際只用到了後面7位,它能夠表示 2^7=128 種狀態,也就是表示128個字符。segmentfault
很顯然,這用來表示字母是足夠的,但要想表示其它語言的字符,128仍是太少了。微信小程序
PS:附送 ASCII 對照表一張:微信
GB2312:性能
既然美國佬只解決了字母和特殊符號的編碼問題,那麼咱們中國人只好實現本身的編碼,從而來表示漢字了。因此這時候出現了 GB2312 編碼(國標碼)。編碼
問題:不幸的是,各個國家都是這麼想的,因此小日本有了 Shift_JIS 編碼,棒子有了 Euc-kr 編碼…..一時之間各國都有了本身的標準,那麼對於一個多語言混合的文原本說,存在着不一樣的編碼規則,最終必然致使亂碼。debug
Unicode:
Unicode 解決了編碼統一的問題。每種語言的每一個字符在 Unicode 的規則下,都只有統一且惟一的對應二進制編碼。它的表示方法是U+[16進制數]
。例如,大寫字母 A 編碼爲 U+0041
,漢字「嚴」編碼爲 U+4E25
。
問題:Unicode 通常用2個字節(也就是16位)表示一個字符,這在表示 ASCII 字符的時候會出現問題。咱們知道,ASCII 字符實際只須要一個字節就夠了,而且最高位甚至都還不須要用到,可是 Unicode 又規定表示一個字符至少須要2個字節,那麼一個 ASCII 字符前面就必需要補0以知足這個規則,例如字母 A 就須要用 00000000 01000001
表示,這些多餘的0是一個極大的資源浪費。
UTF-8:
UTF:實際傳輸過程當中,基於不一樣的系統平臺,對 Unicode 會有不不一樣的實現方式,其實現方式稱爲 Unicode Transformation Format,即 UTF。
做爲 Unicode 的一種實現方式,UTF-8 展示了必定的靈活性——它是一種變長編碼,會根據具體字符來改變所須要的表示字節。其編碼規則只有兩條:
i>. 對於 128 個 ASCII 字符只需一個字節表示,字節的第一位補 0,後面 7 位爲這個字符的 ASCII 二進制數。Unicode 範圍爲 U+0000 至U+007F。
ii>. 對於 n 字節的符號(n>1),第一個字節的前 n 位都設爲 1,第 n+1 位設爲 0,後面字節的前兩位一概設爲 10。剩下的沒有說起的二進制位,所有爲這個符號的 Unicode 碼二進制數。Unicode 範圍由 U+0080 起。
也能夠看下面這張圖:
以漢字「嚴」爲例,演示如何實現 UTF-8 編碼。
「嚴」的 Unicode 是 U+4E25
(二進制數 100111000100101),據表,U+4E25
處在第三行的範圍內(U+0800
~ U+FFFF
),所以「嚴」的UTF-8 編碼須要三個字節,即格式 1110xxxx 10xxxxxx 10xxxxxx
。而後,從「嚴」的最後一個二進制位開始,依次從後向前填入格式中的 x,多出的位補 0。這樣就獲得 UTF-8 編碼(二進制)是 11100100 10111000 10100101
,轉換成十六進制就是 E4B8A5
。
Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線,Fundebug累計處理了20億+錯誤事件,付費客戶有陽光保險、核桃編程、荔枝FM、掌門1對一、微脈、青團社等衆多品牌企業。歡迎你們免費試用!