最近在做乙個**專案需要前台增加乙個
remark（備註）字段傳遞到後台儲存。前台的處理是乙個輸入文字框。
後台接收使用簡單的**：
request.getparameter("remark");由於頁面是非同步的請求，有多個request，為了防止remark欄位丟失，使用儲存到session的方法。
request.getsession().setattribute("remark", request.getparameter("remark"));請求結束之後，發現資料庫裡面除了remark內容為英文的可以儲存成功，中文的全部是被urlencoder編碼之後的亂碼。
於是在網上查了很多資料，結果都沒成功，以為很多都不靠譜，最後發現，中文格式的remark欄位被傳遞到後台之後，都其實是全形字符：
%和％這倆看上去還是有區別的吧？傳參過來使用的是全形字符%，也不知道是哪一步出了錯，反正解碼不了。
於是使用下面函式實現全形到半形的轉換
/**
* 全形對應於ascii表的可見字元從！開始，偏移值為65281
*/
static final char sbc_char_start = 65281; // 全形！
/**
* 全形對應於ascii表的可見字元到～結束，偏移值為65374
*/
static final char sbc_char_end = 65374; // 全形～
/**
* ascii表中除空格外的可見字元與對應的全形字符的相對偏移
*/
static final int convert_step = 65248; // 全形半形轉換間隔
/**
* 全形空格的值，它沒有遵從與ascii的相對偏移，必須單獨處理
*/
static final char sbc_space = 12288; // 全形空格 12288
/**
* 半形空格的值，在ascii中為32(decimal)
*/
static final char dbc_space = ' '; // 半形空格
/**
** 全形字符->半形字元轉換
* 只處理全形的空格，全形！到全形～之間的字元，忽略其他
*
public static string qj2bj(string src)
stringbuilder buf = new stringbuilder(src.length());
char ca = src.tochararray();
for (int i = 0; i < src.length(); i++) else if (ca[i] == sbc_space) else
} return buf.tostring();
}
於是正確的**如下：
string remarkdecodetemp = request.getparameter("remark");
//中文儲存很奇怪，必須全形字符轉半形字元
remarkdecodetemp = bcconvertutil.qj2bj(remarkdecodetemp);
//解碼utf-8
string remarkdecode = urldecoder.decode(remarkdecodetemp,"utf-8");
request.getsession().setattribute("remark", remarkdecode);
萬惡的字串DSA（載入中 ）
這個字串的演算法實在是令人頭大。模擬起來也不是很盡人意。就來這裡總結一下。不然自己看的比較累。半夜機房裡都是在喊這個演算法怎麼這麼妙 來一段簡短的 理解一下orz 自動溢出版 typedef unsigned long long ull 用ull偷個懶而且可以自動溢位 const int maxn ...
Python 2中萬惡的字元編碼
我們知道，在計算機發展初期，計算機只能識別字母，數字和一些基本符號，其使用8位儲存空間儲存所有的內容，也就是2 8 256個不同的結果，這就是ascii碼。在當時的情況下，並沒有想到日後其他語言文字的擴充套件，隨著不斷的發展，對計算機的使用越來越廣泛，使用8位儲存空間早已不能滿足人們的日常需求，所以...
mysql 萬惡的亂碼之when語句中產生的亂碼
使用mysql又遇到問題了，這次是關於亂碼的.其實我也比較了解編碼的問題，也知道亂碼產生的原理，而且網上對mysql的亂碼問題也有比較多的解答，但是今天我遇到的這個亂碼卻比較奇怪,在when語句中產生了奇怪的亂碼。create table my table id int,name varchar 5...