之所以寫這邊博文，是為了驗證之前寫的部落格裡的規則，是否是對的。沒有親自實踐過的東西總是感覺不靠譜。就自己試了下。
utf-8字符集驗證
舉個例子,我用fidder發乙個測試資料，先把字符集設為utf-8
post
user-agent: fiddler
host: 127.0
.0.1:11000
content-length: 21
body
①英文及符號的驗證。
我們可以看到傳送的時候，前面是post，我們去驗證下，看看和上圖中的16進製制是否一致
先查出他們的unicode碼
再按照之前博文寫的匹配規則，得到他們的utf-8格式的二進位制，及十六進製制
上面的unicode碼符合轉化規則中的乙個位元組的規則。 0******x格式
則他們的utf-8形式分別為：
u+0050 = 0050（16） = 1010000（2）
u+004f = 004f （16） = 1001111（2）
u+0053 = 0053（16） = 1010011（2）
u+0054 = 0054（16） = 1010100（2）
所以post的的utf-8格式的16進製制，則是 50,4f,53,54,查出來後和上上圖中的一比對，發現是一致的。
②中文的驗證。
傳送資料的時候，裡面有「羽亦」兩個字。我們驗證下這個
經過查詢得知：
羽的unicode編碼是7fbd,亦的unicode編碼是4ea6
按照之前寫的博文裡面的規則轉化utf-8編碼
他們兩個符合三個位元組的規則，也就是 1110***x 10****** 10******（可填16位unicode碼）
先分別求出 羽，亦 的二進位制編碼
7fbd（羽）
0111 1111 1011 1101（2）
11100111 10111110 10111101 （utf-8）
e7 be bd （16）
4ea6（亦）
0100 1110 1010 0110 （2）
11100100 10111010 10100110 （utf-8）
e4 ba a6 （16）
則這兩個字轉化為utf-8的16進製制編碼應該為 e7,be,bd,e4,ba,a6.從傳送的圖中。傳送後面確實有這樣的編碼。說明這個規則是對的。
2.gbk編碼驗證
fidder測試資料
post
user-agent: fiddler
host: 127.0
.0.1:11000
content-length: 21
body
還是一樣，我們做下驗證
①英文及字元
他們gbk16進製制編碼分別為50,4f,53,54,和上圖傳送時的十六進製制資料，前幾個是一致的。說明死ok的。
②中文的驗證
羽的gbk十六進製制編碼為d3f0，亦的gbk十六進製制編碼為d2e0。
然後去上面的傳送資料找下，發下確實有d3，f2，d2，e2.
3.結論
傳輸格式設定為不同字符集，則就按照相應的字符集編碼規轉化後則傳送資料。從上面的傳送資料中可以看出，同樣的資料utf-8資料集要比gbk的長，理由呢，也顯而易見，因為utf-8編碼是一種可變長的編碼方式。assicc碼他們兩個相同，但是中文的話，gbk中乙個中文始終是兩個位元組。而在utf-8中乙個漢字就是2~4個位元組。關於日期格式輸入的JS驗證
判斷日期格式的函式 function checkdate obj d d gi if str if str var strs str.sprit if strs.length 3 var year paresint strs 0 10 var month paresint strs 1 10 var...
json傳輸格式
json是一種傳輸資料的格式 以物件為樣板，本質上即使物件，但是用途有區別，物件就是本地用的，json是用來傳輸的 物件的屬性加不加雙引號都可以，但是json規定json格式的屬性名必須加上雙引號。var obj var str json stringify obj console.log str ...
json格式的傳輸問題
最近在寫乙個頁面，直接顯示交易中返回的標籤，由於交易返回的標籤裡面的東西很雜很多，並放在json格式裡面傳輸，在除錯的時候報 uncaught syntaxerror unexcepted eof uncaught syntaxerror unexpected token illegal 等錯。這些...