編碼、解碼技術是我們在程式中開發中經常使用到的，對一些敏感資訊的儲存，比如密碼之類的，我們一般是不會直接以明文直接儲存到資料庫的，而是會通過各種演算法，可以是現成的md5（一種雜湊演算法）、或者是hash演算法+salt（混淆因子），甚至是自己定義的一套演算法進行加解密。這裡不想闡述加解密技術，在之前的一篇部落格當中，簡單列舉了兩種基本方法，見.net加解密技術。這裡重點講解一下編碼、解碼以及亂碼的相關問題。
我們先看乙個簡單的例子：
1
2
3
4
stringstr ="abcd";//測試字串
bytebytes = encoding.getencoding("ascii").getbytes(str);//將字串轉成ascii編碼的位元組陣列，這裡的bytes陣列，長度為4，分別對應於abcd的ascii碼97、98、99、100
stringresult = encoding.getencoding("ascii").getstring(bytes);//將位元組陣列轉回為字串
console.writeline(result);//輸出abcd
這裡應用到了ascii編碼。我們知道，ascii碼是國際標準編碼，全稱為：美國資訊交換標準編碼，只能表示127個字元，不能代表漢字，所以我們對漢字進行ascii編碼之後，是不能進行還原的。漢字不能轉變為ascii碼，因此會變成亂碼，對亂碼進行還原也就還原不了了。
正是由於ascii碼的侷限性，不能表示世界上各種語言和符號，因此iso（國際標準化組織）推出了unicode編碼，它可以容納世界上所有的文字和字元。
專案開發中經常會有出現亂碼的情況，這就是由於兩端（服務端、請求端）編譯碼的方式不一致造成的。比如服務端是utf-8編碼，而在客戶端以gbk接收，那麼就會出現亂碼。所以解決亂碼這個問題，思路就是從對方的編碼方式入手，弄清楚對方的編碼是什麼編碼，我這邊就以什麼編碼來解碼。這個解決問題的思路，在我實際專案開發過程中屢試不爽。
比如我們經常會用到web頁面匯出excel的問題。**如下： 1
2
3
4
5
6
7
stringfilename = httputility.urlencode("excel檔名為中文哦.xls");
response.clear();
response.buffer =true;
"content-disposition","attachment;filename="+ filename);
response.contentencoding = system.text.encoding.utf8;
response.contenttype =;
this.enableviewstate =false;
比如：1
最後附乙個我幾年前曾經在實際專案開發中遇到過的乙個問題。
當時也是很著急，花了一天時間也沒有解決那個問題，老是得不到正確的結果。當時的情況是對方將轉變為位元組陣列，然後對這個位元組陣列進行base64編碼之後再對新的字串進行utf-8編碼，最後封裝成xml文件。當然這個過程是我推斷的，因為當時並不知道真實的情況，只是呼叫對方提供的webservice。一般來說，對於中文的編碼還是以utf-8、gbk、gb2312等編碼為主。對方提供的開發文件當中並沒有提及編碼方式，最後經過實驗，用utf-8編碼方式解決。
（其實準確一點來說，當時的情況是不知道是先對位元組陣列進行utf-8編碼還是先對位元組陣列的base64編碼之後得到的一串字串再進行utf-8編碼，有點繞，能理解不？呵呵）
編碼解碼問題
在很多時候我們會碰到編碼問題。例如在編寫文字檔案時，我們用到了日文和英文，在編輯器中顯示正常，是因為，記憶體中採取的是unicode編碼，相容所有字元 但是我們儲存文字檔案是確是用了gbk 只支援中文和英文 編碼儲存的，這時候就會出現儲存出錯。解決方法 存檔時，使用與編寫文字檔案相容的編碼進行儲存。...
關於web請求中的編碼解碼問題
以下編譯碼都是針對內容包含中文的情況，否則也不需要編譯碼 1 url編譯碼 url例子 http localhost 80 contextpath servletpath pathinfo?querystring url中文主要會出現在pathinfo和querystring中，這兩部分的編譯碼是不...
關於Base64編碼 解碼
用數字證書簽名或者生成md5摘要結果都是byte陣列，為了方便對簽名結果放在xml中進行傳輸，一般先用base64進行編碼，生成一串可見的ascii字元。接收方收到後在用base64進行decoder生成byte陣列。可進行base64編碼 解碼處理的類有 org.apache.commons.co...