• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            大龍的博客

            常用鏈接

            統計

            最新評論

            new String(str.getBytes("ISO-8859-1"),"GBK")是怎么樣一種機制 --- 轉

            除了UTF-16,其它字符集定義時都重復。
            比如漢字“我”,假設它的值是22530(只是假設,具體多少我沒查)
            而日文的“マ”的值也可能是22530(也是假設)或韓文的“?”
            在網絡上傳輸是不能以高字節傳輸,因為網絡底層最后只認無符號char,相當于java中的byte,所以
            22530這個int要轉換為字節數組,
            byte[0] = (22530 >> 8)&0xFF;
            byte[1] = 22530 &0xFF;
            具體多少我沒算,假設是byte[125,231]
            這樣的字節傳到服務端到是表示漢字“我”還是日文的“マ”還是其它狗屁?
            一般通訊協議中會告訴對字符集,比如HTTP在請求時告訴服務端:
            ContentType="xxxxxxxxxx";charset="GKB";
            這時服務端就知道現在接收到的[125,231]是GKB的“我”而不是其它文字。
            上面是標準的通信過程。但如果有些水平很差的程序員在提交請求時沒有通知服務端字符集,那服務端就沒辦法了。
            只好按最常用的字符集來猜一個默認的。
            這還不錯,最要命的是寫服務器的程序員水平和見識很差時,就要命了。就象寫老版本的TOMCAT的程序員,他自己生在西方,以為全世界所有人都用的是26個字母加一些符號,所以他不管客戶端提交什么都按ISO-8859-1來算,結果可想而知。
            沒辦法,誰讓我們用GBK的人不會寫tomcat呢,只好先把讓那個差勁的程序員錯誤生成的String用ISO-8859-1還原成
            [125,231],再重新用GKB生成String.

            posted on 2011-07-02 16:20 大龍 閱讀(661) 評論(0)  編輯 收藏 引用

            国产精品日韩深夜福利久久 | 久久99精品久久久久久秒播| 人妻精品久久无码区| 国产精品岛国久久久久| 久久九九青青国产精品| 亚洲人成网站999久久久综合| 亚洲国产精品久久电影欧美| 精品久久久久久久| 国产69精品久久久久APP下载| 国产精品久久久久jk制服| 久久精品国产亚洲AV不卡| 午夜精品久久久久久中宇| 久久精品一区二区国产| 久久婷婷是五月综合色狠狠| 久久久91精品国产一区二区三区| 亚洲成av人片不卡无码久久| 精品久久久久香蕉网| 免费一级做a爰片久久毛片潮| 国产精品美女久久久久| 青青草原综合久久大伊人| 久久男人AV资源网站| 国产精品久久成人影院| 无码日韩人妻精品久久蜜桃 | 久久精品亚洲男人的天堂| 99久久er这里只有精品18| 久久99九九国产免费看小说| 香蕉久久一区二区不卡无毒影院| 久久人妻无码中文字幕| 久久综合色区| 精品人妻伦一二三区久久| 大蕉久久伊人中文字幕| 国产精品久久久久无码av| 午夜久久久久久禁播电影| AV无码久久久久不卡蜜桃| 日本久久久久久久久久| 久久夜色精品国产www| segui久久国产精品| 久久99精品国产麻豆蜜芽| 久久久精品波多野结衣| 久久久99精品成人片中文字幕| 久久久精品人妻无码专区不卡|