java漢字位元組

① java中如何計算一個字元串的byte長度(一個漢字多少字元)

中文並不一定是占兩個位元組的，具體佔多少位元組是跟具體的編碼方式相關的。
比如說:GB2312、GBK、GB18030
編碼是佔用兩個位元組的，但是
UTF-8
編碼的話至少需要佔用三個位元組。
有一個簡單方法，就是把大於
0xff
的字元都作為兩個字元(當然是在
GBK
環境下)
Java
code
publicstaticint
count(String
str)
{
if(str
==null||
str.length
==0)
{
return0;
}
int
count
=0;
char[]
chs
=
str.toCharArray();
for(int
i
=0;
i
<
chs.length;
i++)
{
count
+=
(chs[i]
>0xff)
?2
:
1;
}
return
count;
}
或者你直接使用
int
len
=
str.getBytes("gbk");上面代碼假設你的資料庫編碼格式是
GBK
的，而不是
UTF-8
的，如果是
UTF-8
的話，上面的代碼無效!1位元組等於8比特，一個字母是1位元組，而一個漢字要用2個位元組。一個漢字=2個字元

② Java中文字元所佔的位元組數是多少

採用GB2312或GBK編碼方式時，一個中文字元佔2個位元組；而採用UTF-8編碼方式時，一個中文字元會佔3個位元組。

③ java中一個漢字 位元組

你這個問題涉及到漢字的生成原理，漢字是由區碼和位碼組成的，在組成一個漢字之後，把這兩個位元組認為是一個字元，而在計算長度的時候又是看有幾個字元，所以「國人」的length=2了。
您的進步是我最大的動力，如果你覺得我回答的合理的話，請給我多加分。謝謝，如果不明白的話，請給我留言。大家相互學習啊！ 加油！

④ java一個漢字占幾個位元組

1、首先，定義好主類程序，並為程序添加main程序入口。

⑤ java中如何計算一個字元串的byte長度（一個漢字多少字元）

中文並不一定是占兩個位元組的，具體佔多少位元組是跟具體的編碼方式相關的。 比如說：GB2312、GBK、GB18030 編碼是佔用兩個位元組的，但是 UTF-8 編碼的話至少需要佔用三個位元組。 有一個簡單方法，就是把大於 0xff 的字元都作為兩個字元（當然是在 GBK 環境下） Java code publicstaticint count(String str) { if(str ==null|| str.length ==0) { return0; } int count =0; char[] chs = str.toCharArray(); for(int i =0; i < chs.length; i++) { count += (chs[i] >0xff) ?2 : 1; } return count; } 或者你直接使用 int len = str.getBytes("gbk");上面代碼假設你的資料庫編碼格式是 GBK 的，而不是 UTF-8 的，如果是 UTF-8 的話，上面的代碼無效！1位元組等於8比特，一個字母是1位元組，而一個漢字要用2個位元組。一個漢字=2個字元

⑥ Java 漢字位元組問題

java中，只要是字元，不管是數字還是英文還是漢字，都占兩個位元組，都是一個char。
char
c1
=
'中';
char
c2
=
'A';
char
c3
=
'1';
確切說，Unicode編碼是指一類編碼的統稱，而非某個具體編碼。
utf-8跟unicode是不一樣的。

⑦ java中英文字母漢字數字各佔多少位元組

java採用Unicode編碼，不論漢字、字母、數字，每個字元都佔用2位元組。

⑧ java 中字元和漢字編碼佔位元組問題

大概來說，Unicode編碼系統可分為編碼方式和實現方式兩個層次。

[編輯] 編碼方式
Unicode的編碼方式與ISO 10646的通用字元集（Universal Character Set，UCS）概念相對應，目前實際應用的Unicode版本對應於UCS-2，使用16位的編碼空間。也就是每個字元佔用2個位元組。這樣理論上一共最多可以表示216即65536個字元。基本滿足各種語言的使用。實際上目前版本的Unicode尚未填充滿這16位編碼，保留了大量空間作為特殊使用或將來擴展。

上述16位Unicode字元構成基本多文種平面（Basic Multilingual Plane，簡稱BMP）。最新（但未實際廣泛使用）的Unicode版本定義了16個輔助平面，兩者合起來至少需要佔據21位的編碼空間，比3位元組略少。但事實上輔助平面字元仍然佔用4位元組編碼空間，與UCS-4保持一致。未來版本會擴充到ISO 10646-1實現級別3，即涵蓋UCS-4的所有字元。UCS-4是一個更大的尚未填充完全的31位字元集，加上恆為0的首位，共需占據32位，即4位元組。理論上最多能表示231個字元，完全可以涵蓋一切語言所用的符號。

BMP字元的Unicode編碼表示為U+hhhh，其中每個h 代表一個十六進制數位。與UCS-2編碼完全相同。對應的4位元組UCS-4編碼後兩個位元組一致，前兩個位元組的所有位均為0。

關於Unicode和ISO 10646及UCS的詳細關系 ，請參看通用字元集。

[編輯] 實現方式
Unicode的實現方式不同於編碼方式。一個字元的Unicode編碼是確定的。但是在實際傳輸過程中，由於不同系統平台的設計不一定一致，以及出於節省空間的目的，對Unicode編碼的實現方式有所不同。Unicode的實現方式稱為Unicode轉換格式（Unicode Translation Format，簡稱為UTF）。

例如，如果一個僅包含基本7位ASCII字元的Unicode文件，如果每個字元都使用2位元組的原Unicode編碼傳輸，其第一位元組的8位始終為0。這就造成了比較大的浪費。對於這種情況，可以使用UTF-8編碼，這是一種變長編碼，它將基本7位ASCII字元仍用7位編碼表示，佔用一個位元組（首位補0）。而遇到與其他Unicode字元混合的情況，將按一定演算法轉換，每個字元使用1-3個位元組編碼，並利用首位為0或1進行識別。這樣對以7位ASCII字元為主的西文文檔就大大節省了編碼長度（具體方案參見UTF-8）。類似的，對未來會出現的需要4個位元組的輔助平面字元和其他UCS-4擴充字元，2位元組編碼的UTF-16也需要通過一定的演算法進行轉換。

再如，如果直接使用與Unicode編碼一致（僅限於BMP字元）的UTF-16編碼，由於每個字元佔用了兩個位元組，在Macintosh (Mac)機和PC機上，對位元組順序的理解是不一致的。這時同一位元組流可能會被解釋為不同內容，如某字元為十六進制編碼4E59，按兩個位元組拆分為4E和59，在Mac上讀取時是從低位元組開始，那麼在Mac OS會認為此4E59編碼為594E，找到的字元為「奎」，而在Windows上從高位元組開始讀取，則編碼為U+4E59的字元為「乙」。就是說在Windows下以UTF-16編碼保存一個字元「乙」，在Mac OS里打開會顯示成「奎」。此類情況說明UTF-16的編碼順序若不加以人為定義就可能發生混淆，於是在UTF-16編碼實現方式中使用了大端序（Big-Endian， 簡寫為UTF-16 BE）、小端序（Little-Endian，簡寫為UTF-16 LE）的概念，以及可附加的位元組順序記號解決方案，目前在PC機上的Windows系統和Linux系統對於UTF-16編碼默認使用UTF-16 LE。（具體方案參見UTF-16）

此外Unicode的實現方式還包括UTF-7、Punycode、CESU-8、SCSU、UTF-32等，這些實現方式有些僅在一定的國家和地區使用，有些則屬於未來的規劃方式。目前通用的實現方式是UTF-16小尾序（LE）、UTF-16大尾序（BE）和UTF-8。在微軟公司Windows XP操作系統附帶的記事本（Notepad）中，「另存為」對話框可以選擇的四種編碼方式除去非Unicode編碼的ANSI（對於英文系統即ASCII編碼，中文系統則為GB2312或Big5編碼） 外，其餘三種為「Unicode」（對應UTF-16 LE）、「Unicode big endian」（對應UTF-16 BE）和「UTF-8」。

目前輔助平面的工作主要集中在第二和第三平面的中日韓統一表意文字中，因此包括GBK、GB18030、Big5等簡體中文、繁體中文、日文、韓文以及越南喃字的各種編碼與Unicode的協調性被重點關注。考慮到Unicode最終要涵蓋所有的字元，從某種意義而言，這些編碼方式也可視作Unicode的出現於其之前的既成事實的實現方式，如同ASCII及其擴展Latin-1一樣，後兩者的字元在16位Unicode編碼空間中的編碼第一位元組各位全為0，第二位元組編碼與原編碼完全一致。但上述東亞語言編碼與Unicode編碼的對應關系要復雜得多。

⑨ Java 中，數字,漢字,英文字母,...佔多少位元組

半形的數字和英文字母以及標點符號佔用1位元組,全形數字,英文字母和漢字佔用2位元組