• <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)  編輯 收藏 引用

            精品综合久久久久久888蜜芽| 天天躁日日躁狠狠久久| 99久久婷婷免费国产综合精品| 囯产精品久久久久久久久蜜桃| 久久香综合精品久久伊人| 99久久99这里只有免费的精品| 国产一区二区精品久久岳| 久久狠狠爱亚洲综合影院| 久久综合久久综合久久| 精品伊人久久大线蕉色首页| 国产精品对白刺激久久久| 久久综合五月丁香久久激情| 久久久精品国产sm调教网站| 91精品免费久久久久久久久| 亚洲va久久久噜噜噜久久| 国产精品亚洲综合专区片高清久久久| 亚洲午夜久久久久久久久久| 91久久精品国产91性色也| 婷婷久久久亚洲欧洲日产国码AV| 精品免费久久久久国产一区 | 久久最近最新中文字幕大全| 欧美一区二区久久精品| 久久国产乱子伦精品免费强| 无码AV波多野结衣久久| 深夜久久AAAAA级毛片免费看| 久久综合九色综合久99| 国产成年无码久久久免费| 亚洲精品WWW久久久久久| 一本一道久久精品综合| 99久久人妻无码精品系列蜜桃 | 亚洲AV无码久久| 亚洲七七久久精品中文国产| 国产免费久久久久久无码| 久久99国产精品久久久| 91精品国产91久久综合| 久久精品无码一区二区无码| 久久天天躁狠狠躁夜夜avapp| 一级做a爰片久久毛片毛片| 久久精品综合网| 影音先锋女人AV鲁色资源网久久| 综合网日日天干夜夜久久|