今天在網上遇到乙個問題，覺得挺有意思，就幫人解答了。
在編碼為latin1的mysql資料庫中插入中文資料，由另乙個系統將latin1編碼的字串轉碼為gbk後作為簡訊內容發出。
import (
"golang.org/x/text/encoding/charmap"
"golang.org/x/text/encoding/simplifiedchinese"
)func convert(src string) (string, error)
latin1, err := charmap.iso8859_1.newdecoder().bytes(gbk)
if err != nil
return string(latin1), nil
}複製**
因為iso-8859-1編碼範圍使用了單位元組內的所有空間，在支援iso-8859-1的系統中傳輸和儲存其他任何編碼的位元組流都不會被拋棄。換言之，把其他任何編碼的位元組流當作iso-8859-1編碼看待都沒有問題。這是個很重要的特性，mysql資料庫預設編碼是latin1就是利用了這個特性。ascii編碼是乙個7位的容器，iso-8859-1編碼是乙個8位的容器。首先說一下處理編碼問題的原則：保證寫和讀都使用同一套規則。
依照這個原則處於中間環節的資料庫不支援中文的問題怎麼處理，要先看對方系統怎麼讀資料：將latin1編碼的字串轉碼為gbk後作為簡訊內容那麼我們任務就是：將簡訊內容以gbk編碼強制轉碼為iso-8859-1然後存入資料庫清楚了任務，後面就是實現了。
utf8->gbk，golang是utf8編碼的，那麼首先轉碼gbk。這裡需要注意的一點是不能用encoder.string()方法，因為這樣會強制將已經編碼的gbk位元組流用golang內建的utf8 decoder解碼，而這樣得到的亂碼string將無法還原回原本的gbk位元組流。
gbk位元組流強制轉iso-8859-1位元組流，怎麼做呢？就是什麼都不做。。。
iso-8859-1位元組流->utf8 string，我不是很確定如何在sql中提交byte，那麼乙個保守的做法就是先將iso-8859-1轉碼為utf8，然後由資料庫驅動將utf8轉回iso-8859-1提交。
還有一點可以提一下，由於iso-8859-1不支援中文，所以直接提交utf8中文，資料庫驅動會直接將中文替換為？。
乙個複雜的sql
select f.course node info id as nodeid,c.course node name as nodename,c.course node type as nodelevel,c.course code,case when select course node info ...
golang寫的乙個分頁控制項。
直接放 吧，基本不用改，直接用了。package components import math date 2019 04 01 description 分頁控制項 pages 分頁控制項 type pages struct startrecord 設定分頁查詢時起始位置 func p pages s...
乙個討厭的編碼問題
編碼問題很討厭。昨天就碰到了乙個，花了幾個小時才解決。使用dotnetzip這個庫自動打包資料夾，原來的 是 var dir new directoryinfo c foo using zipfile zip new zipfile encoding.utf8 看上去很正常，也似乎能work，成功打...