我們知道，在計算機發展初期，計算機只能識別字母，數字和一些基本符號，其使用8位儲存空間儲存所有的內容，也就是2^8=256個不同的結果，這就是ascii碼。在當時的情況下，並沒有想到日後其他語言文字的擴充套件，隨著不斷的發展，對計算機的使用越來越廣泛，使用8位儲存空間早已不能滿足人們的日常需求，所以unicode(萬國碼)就這樣誕生了。顧名思義，unicode包含了所有國家所有不同的文字，它的儲存空間由8位儲存空間提公升到了至少16位儲存空間，也就是至少2^16=65536個不同的結果，這足以滿足人們日常的需要，這就恰恰是python2中使用的字元編碼，但是問題又隨之而來，如果在初期使用ascii字元編碼儲存數字1，那麼它的儲存方式為0000001;而使用unicode儲存數字1的話，那麼儲存方式就擴大為00000000 00000001，雖然這樣儲存的資料沒有任何問題，但是會白白浪費了很大的空間。聰明的人們又
針對unicode發明了utf-8、 gbk、gb2312等字元編碼，這類字元編碼都是針對unicode編碼的進一步優化，它們都處於同一級的字元編碼。
以utf-8字元編碼為例來說能夠滿足儲存於ascii字元編碼的(數字、字元、字母)都會按照8位儲存空間儲存，當遇到歐洲文字時會選擇16位儲存空間進行儲存，也就是兩個位元組儲存，當遇到漢字會使用24位儲存空間儲存，也就是三個位元組儲存。由此可以看出，
utf-8、gbk等相比對unicode它是對其乙個優化，針對儲存不同的文字，使用不同的儲存空間位數。
從上可知，在python2中檔案起始要明確指定字元編碼，如果不指定系統會直接報錯，而這就涉及到了字元編碼的轉換問題：當從utf-8字元編碼轉換到gbk字元編碼是不能夠直接轉換的，需要從utf-8編碼執行decode方法進行解碼操作，此時的字元編碼已轉換為unicode，然後再將unicode編碼使用encode方法進行編碼操作，轉換為gbk字元編碼。之所以說python2中字元編碼讓人頭疼，指的就是utf-8同級的字元編碼轉換gbk同級的字元編碼，需要用到unicode字元編碼來進行轉化。(參考下圖)
在python3中預設全域性指定utf-8字元編碼，即使沒有指定字元編碼設定，依然能夠正常的列印輸出；在python中不存在解碼操作的必要，但仍需要編碼操作。
python2中的不同字元編碼之間如果需要相互轉換，需要借助unicode來完成，不能做到不同字元編碼之間的相互轉換；而這點在python3中已經得到優化，將所有字元編碼預設設定為utf-8，徹底解決了因為字元編碼頭疼的問題。
萬惡的db2總結
1 修改表結構或重新建表後，對錶進行任何操作都不被允許，因為表不活動，需要對錶進行reorg操作 來恢復。語句 reorg table 2 1個中文字元在表結構中佔3個varchar字元 1個字元佔乙個varchar字元 1個資料佔乙個varchar字元 3 decimal m,n 整數的位數不能大...
萬惡的字串DSA（載入中 ）
這個字串的演算法實在是令人頭大。模擬起來也不是很盡人意。就來這裡總結一下。不然自己看的比較累。半夜機房裡都是在喊這個演算法怎麼這麼妙 來一段簡短的 理解一下orz 自動溢出版 typedef unsigned long long ull 用ull偷個懶而且可以自動溢位 const int maxn ...
JSP傳參亂碼，萬惡的全形字符
最近在做乙個 專案需要前台增加乙個 remark 備註 字段傳遞到後台儲存。前台的處理是乙個輸入文字框。後台接收使用簡單的 request.getparameter remark 由於頁面是非同步的請求，有多個request，為了防止remark欄位丟失，使用儲存到session的方法。reques...