前言
前段時間發表了Go中的HTTP請求之——HTTP1.1請求流程分析，所以這兩天本來打算研究HTTP2.0的請求源碼，結果發現太複雜就跑去逛知乎了，然後就發現了一個非常有意思的提問「golang 特殊字符的string怎麼轉成[]byte?」。為了轉換一下心情， 便有了此篇文章。
問題
原問題我就不碼字了，直接上圖：
看到問題，我的第一反應是ASCII碼值範圍應該是0~127呀，怎麼會超過127呢？直到實際運行的時候才發現上圖的特殊字符是『』（如果無法展示，記住該特殊字符的unicode是\u0081），並不是英文中的句號。
unicode和utf-8的恩怨糾葛
百度百科已經把unicode和utf-8介紹的很詳細了，所以這裡就不做過多的闡述，僅摘抄部分和本文相關的定義：
Unicode為每個字符設定了統一併且唯一的二進位編碼，通常用兩個字節表示一個字符。UTF-8是針對Unicode的一種可變長度字符編碼。它可以用來表示Unicode標準中的任何字符。UTF-8的特點是對不同範圍的字符使用不同長度的編碼。對於0x00-0x7F之間的字符，UTF-8編碼與ASCII編碼完全相同。go中的字符
眾所周知，go中能表示字符的有兩種類型，分別是byte和rune，byte和rune的定義分別是：type byte = uint8和type rune = int32。
uint8範圍是0-255，只能夠表示有限個unicode字符，超過255的範圍就會編譯報錯。根據上述關於unicode的定義，4位元組的rune完全兼容兩字節的unicode。
我們用下面的代碼來驗證：
上述的程序根本無法運行，因為第二行編譯會報錯，vscode給到了十分詳細的提示：
'新' (untyped rune constant 26032) overflows byte。
接下來，我們通過下面的代碼來驗證字符和unicode和整型的等價關係：
根據上面的代碼輸出的3個true可以知道，字符和unicode和整形是等價，並且整型也能轉回字符的表現形式。
go中的字符串是utf8編碼的
根據golang官方博客https://blog.golang.org/strings的原文：
Go source code isalways UTF-8.A string holds arbitrary bytes.A string literal, absent byte-level escapes, always holds valid UTF-8sequences.
翻譯整理過來其實也就是兩點：
go中的代碼總是用utf8編碼，並且字符串能夠存儲任何字節。沒有經過字節級別的轉義，那麼字符串是一個標準的utf8序列。有了前面的基礎知識和字符串是一個標準的utf8序列這一結論後我們接下來對字符串「」（如果無法展示，記住該特殊字符的unicode是\u0081）手動編碼。
Unicode到UTF-8的編碼方對照表：
字符『』（如果無法展示，記住該特殊字符的unicode是\u0081）的二進位表示為
10000001，16進位表示為0x81。
根據unicode轉utf8的對照表，0x7f < 0x81 < 0x7ff，所以此特殊字符需佔兩個字節，並且要套用的utf8模版是110xxxxx 10xxxxxx。
我們按照下面的步驟對10000001轉為utf8的二進位序列：
第一步：根據x數量對特殊字符的高位補0。x的數量是11，所以需要對特殊字符的高位補3個0，此時特殊字符的二進位表示為：00010000001。
第二步：x有兩個部分，且長度分別是5和6，所以對00010000001由底位向高位分別截取6位和5位，得到000001和00010。
第三步：將000001和00010由低位向高位填充至模版110xxxxx 10xxxxxx，可得到utf8的二進位序列為：11000010 10000001。
我們通過go對二進位轉為整型：
綜上：當用字符轉字節時輸出的是字符本身的整型值，當用字符串轉字節切片時，實際上是輸出的是utf8的字節切片序列(go中的字符串存儲的就是utf8位元組切片)。此時，我們回顧一下最開始的問題，就會發現輸出是完全符合預期的。
go中的rune
筆者在這裡猜測提問者期望的結果是「字符串轉字節切片和字符轉字節的結果保持一致」，這時rune就派上用場了，我們看看使用rune的效果：
由上可知用rune切片去轉字符串時，它是直接將每個字符轉為對應的unicode。
我們通過下面的代碼模擬字符串轉為[]rune切片和[]rune切片轉為字符串的過程：
字符串轉為rune切片:
上述代碼中utf8.DecodeRune的作用是通過傳入的utf8位元組序列轉為一個rune即unicode。
rune切片轉為字符串:
上述代碼中utf8.EncodeRune的作用是將一個rune轉為utf8位元組序列。
綜上：對於無法確定字符串中僅有單字節的字符的情況， 請使用rune，每一個rune類型代表一個unicode字符，並且它可以和字符串做無縫切換。
理解go中的字符串其實是字節切片
前面已經提到了字符串能夠存儲任意字節數據，而且是一個標準的utf8格式的字節切片。那麼本節將會通過代碼來加深印象。
由上述的代碼可知，我們通過遊標按字節訪問字符串得到的結果和字符串轉為字節切片是一樣的，因此可以再次確認字符串和字節切片是等價的。
通常情況下我們的字符串都是標準utf8格式的字節切片，但這並不是說明字符串只能存儲utf8格式的字節切片，go中的字符串可以存儲任意的字節數據。
仔細閱讀上面的代碼和輸出，前5行的輸出應該是沒有疑問的。但是第6行輸出卻和預期有出入。
前面提到了字符串可以存儲任意的字節數據，那如果存儲的字節數據不是標準的utf8位元組切片就會出現上面的問題。
我們已經知道通過utf8.DecodeRune可以將字節切片轉為rune。那如果碰到不符合utf8編碼規範的字節切片時，utf8.DecodeRune會返回一個容錯的unicode\uFFFD，這個unicode對應上面輸出的16進位0xfffd。
問題也就出現在這個容錯的unicode\uFFFD上，因為字節切片不符合utf8編碼規範無法得到正確的unicode，既\uFFFD佔據了本應該是正確的unicode所在的位置。這個時候再將已經含有容錯字符的rune切片轉為字符串時，字符串存儲的就是合法的utf8位元組切片了，因此第六行輸出的是含有\uFFFD的合法utf8位元組切片，也就產生了和最初始的字節切片不一致的情況了。
：在平時的開發中要注意rune切片和byte切片的相互轉換一定要基於沒有亂碼的字符串(內部是符合utf8編碼規則的字節切片)，否則容易出現上述類似的錯誤。
字符串的多種表示方式
本節算是擴展了，在開發中還是儘量別用這種特殊的表示方式，雖然看起來很高級但是可讀性太差。
下面直接看代碼：
目前筆者僅發現unicode和單字節的16進位可以直接用在字符串中， 歡迎讀者提供更多的表示方式以供交流。
最後，祝大家讀完此篇文章後能夠有所收穫。