現代計算機技術起源於美國，編碼自然也起源於美國。ASCII（美國信息交換標準代碼）代碼是第壹套通用計算機代碼，包含英文字符、阿拉伯數字和壹些常用符號，壹個***128，占壹個字節，第壹位數字由0補充。例如，常用的大寫字母A是65（0100001），小寫字母A是97，因此在JAVA中，我們可以這樣轉換大小寫:
從字面上看，字符集是包含指定字符的集合，編碼是將單詞轉換為相應的數字代碼，這也是正確的。與AscII代碼壹樣，它包含128個特定字符，每個字符都分配有壹個序列號，這可以稱為字符集。編碼就像在字符集中查找相應的序列號，然後根據編碼規則將序列號轉換為特定的值，這就是所謂的編碼。AscII碼相對簡單，僅占用壹個字節，其編碼結果與碼表的序列號值相同，因此其字符集和編碼概念的區分並不嚴格。
隨著計算機技術的發展，AscII碼只能用於限制拉丁字符，這嚴重影響了非英語國家的使用。因此，各個國家和地區都制定了與當地語言相對應的編碼方法。GB2312是國家標準總局制定的漢字字符集標準代碼，GB代表國家標準。事實上，除了中文之外，GB2312還包含拉丁字符、希臘字符、日語、俄語和其他常見字符。
GB2312占用兩個字節，這意味著它可以容納的字符數為2 16 ***65536。為了便於管理，GB2312將所有字符分為若幹個96字符的組，每個組稱為區域，字符所在的位置稱為位置，這樣每個字符都有相應的區號。例如，漢字“安”所在的地區是16地區，位置序號是18，其區號是1618。有了區號怎麽轉換成代碼？很簡單，把區號分開，區號和位置序號分別加0xA0，就是對應的代碼。因此“安”的GB2312代碼為0xa 0+160 xa 0+18 = 0xb0b 2。
至此，GB2312的介紹基本完畢，但仍有壹個疑問。GB2312中的AscII碼如何處理？事實上，GB2312與AscII碼兼容。如上所述，GB2312代碼是通過在位置代碼上分別加0得到的，A的代碼是1010，也就是說GB2312的代碼必須以1開頭，而AscII的代碼是
GBK是GB2312的升級版，不僅包含常用漢字，還包含繁體字、偏旁部首、生僻字等，幾乎可以滿足所有使用漢字的場景。
Unicode是國際編碼組織制定的字符編碼方案，可以容納世界上所有的字符和符號。範圍從0-0x10FFFF，分為17組。每個組稱為壹個平面，每個平面包含65536個字符。事實上，目前只有少數平面被使用，例如最常用的基本平面（BMP）。範圍是0-0xFFFF。從0x0010000到0x10fffffff的其他範圍稱為輔助平面（SMP）。事實上，BMP基本上可以滿足我們日常使用中的所有要求。
Unicode幾乎包含了全世界使用的所有字符，例如漢字“安”的Unicode編碼是0x5B89。
什麽是utf編碼？上面介紹了Unicode，它是壹個字符集，指定了每個字符對應的數值。utf是壹種特定的實現方法，它使用各種方法來存儲字符的相應數值，並根據不同的實現方法分為utf-8/16/32。
Utf8是壹種可變長度代碼。如果是1字節，則與Ascall代碼相同。當它是多字節時，第壹個字節的第壹位開始填充1，幾個1字節代表幾個字節。例如110x xxxx表示兩個字節，第二個字節從頭到尾是65438。
以漢字“安”為例，其Unicode編碼為0x5B89，將其轉換為二進制並填充到utf-8的空格中，多余的位置用0填充即可得到結果:0xE5AE89。
現在我們再來看看字符集和編碼，很明顯Unicode是字符集，而utf-8編碼是實現字符集的壹種方式，它們不是同壹個概念。
讓我們來看看utf-16編碼。utf-16的長度固定為2或4個字節。通常，我們可以使用2個字節，這對應於Unicode中的基本平面BMP。編碼為Unicode編碼，小於2字節的數字前面用0填充，也是漢字“安”。它的Unicode編碼是0x5B89，所以UTF-6549。因此，AscII代碼也將占用兩個字節，並且會浪費壹些空間。對Unicode輔助平面的字符進行編碼時，utf-16占用4個字節，平時幾乎不使用，具體編碼規則就不介紹了。
Utf-32編碼占用4個字節，對應於所有Unicode代碼。這種編碼方式基本沒有必要，也不需要深入理解。
這些詞通常出現的頻率較低。LE代表小端字節序、小端字節序，BE代表大端字節序和大端字節序，它們分別代表了計算機領域數據存儲的兩種方式。
大端序列:
小端:
事實上，我們不需要關心電腦在日常使用中的使用方式。但是，在對UTF-16進行編碼時，它也有兩種編碼方法，例如0x5E89，大端值依次為0x5E89，小端值依次表示為0x895E。為了區分這兩種方法，在對UTF-16進行編碼時，會在數據流的開頭添加壹個統壹的標識符，0xFEFF表示相應的大端字節序。
bom全稱字節序標，是字節序標。除了utf-16之外，utf-8還可以添加bom，其bom固定為0xEFBBBF。當選擇帶bom的utf-8作為編碼方法時，此BOM將出現在生成的文件流中。為什麽utf-8不需要bom？因為utf8的長度是可變的，它根據第壹個字節信息來判斷每個字符的長度，不存在正負順序的問題。我們每天使用的utf-8沒有bom。
看了字符編碼的介紹，這裏有壹個疑問。java中的char類型可以存儲漢字嗎？
java中Char占用了兩個字符，很容易得出壹個結論:如果采用utf-8，則無法存儲中文。其他編碼方式如GB2312和utf-16可以用來存儲中文，對嗎？
事實上，事情沒那麽簡單。無論我們在編輯器中選擇什麽編碼方法，它對java中的char都沒有影響。事實上，char對應於Unicode的基本平面BMP。我們在瀏覽器中選擇的編碼只對應於文件的保存方式，與char使用的編碼無關。同樣，如果我們在壹個新字符串中指定壹個編碼，該編碼將只對該字符串生效，而Java中的char在編譯器中是死的，它對應於BMP，也可以被視為utf-16的2字節部分。
所以ava中的char類型是否可以存儲漢字當然可以，但只能對應BMP部分，各種繁體字都無能為力。