前面提到字元型別是一種新的變數型別，然而編碼實踐的過程中卻發現，某個具體的字元值居然可以賦值給整型變數！就像下面的例子程式碼那樣，把字元值賦給整型變數，編譯器不但沒報錯，而且還能正常執行！

	// 字元允許直接賦值給整型變數
	private static void charToInt() {
		int a = 'A';
		System.out.println("int a="+a);
		int tian = '田';
		System.out.println("int tian="+tian);
	}

馬上執行上面的測試程式碼，輸出日誌如下所示：

int a=65
int tian=30000

之所以出現字元變成整數的情況，是因為計算機為了方便處理，將包括英文在內的拉丁字母都採用數字編碼，這樣字元才能儲存在只認得二進位制數的計算機系統當中。因為計算機程式設計誕生在西方，所以早期程式語言只支援英語和其他西歐語言。英文字母才26個，區分大小寫也才52個，加上標點符號等等，屈指一算總共128個頂天了，只消一個位元組來表達西方世界的字元綽綽有餘（一個位元組為8位二進位制數，可表達255個數值）。這套單位元組的字元編碼標準源自美國，故而它被稱作ASCII碼（全稱American Standard Code for Information Interchange，意思是美國資訊交換標準程式碼）。
可是計算機程式設計傳播到其它國家時發現了問題，很多國家都有自己的語言文字，像常用的漢字就有三千多個，單位元組的ASCII碼根本不夠用。於是後來又制定了DBCS標準（Double-Byte Character Set，意思是雙位元組字符集），該標準使用兩個位元組來表示一個字元，這樣一共可以表示256*256-1=65535個字元，其中前128個字元與ASCII碼保持一致，剩餘的位置留給了別的語言文字和擴充套件符號。其中以漢字為主的東亞象形文字佔據了從0x3000到0x9FFF之間的編碼，足足佔去了DBCS所有字元的十六分之七，真要感謝老祖宗的聰明才智，為數千年之後的我們爭取了將近一半的編碼空間。
既然字元值允許直接賦給整型變數，反過來整數（0-65535）也能直接賦給字元變數。譬如整數65賦值給字元變數就變成了字母“A”，整數30000賦值給字元變數就變成了漢字“田”。當然只有0到65535之間的整數才能正常給字元變數賦值，因為其它整數不在Java的字元型範圍之內。下面是將整數賦值給字元型變數程式碼例子：

	// 0-65535之間的整數允許直接賦值給字元變數。字元型別佔兩個位元組
	private static void intToChar() {
		char a = 65;
		System.out.println("char a="+a);
		char tian = 30000;
		System.out.println("char tian="+tian);
		// 以漢字為主的東亞象形文字（中日韓）佔據了從0x3000到0x9FFF之間的編碼
		char begin = 0x3000;
		System.out.println("chinese begin="+begin);
		char end = 0x9FFF;
		System.out.println("chinese end="+end);
		char max = 65535; // 字元型可表達的範圍是0-65535
		System.out.println("char max="+max);
	}

上面說道整型數與字元型之間允許直接相互賦值，也就是說可以把字元變數當作整型變數看待，這意味著字元變數也能參與加減乘除四則運算。不過一旦字元變數參與計算，由於編譯器不能確定計算結果是否還落在0-65535的整數區間，因此就必須顯式把運算結果強制轉換成字元char型別。以列印所有的大寫英文字母為例，只要指定了初始字元為“A”，那麼便能對初始字元逐次加一，從而完成從“A”到“Z”之間所有字元的遍歷操作。具體的大寫字母遍歷程式碼示例如下：

	// 字元變數允許跟整數直接加減乘除
	private static void printCapital() {
		char a = 'A';
		for (int i=0; i<26; i++) {
			// 因為不確定a+i之和是否超出0-65535的範圍，所有需要強制轉換成字元型別
			char capital = (char) (a+i);
			System.out.println("capital="+capital);
		}
	}

　　

更多Java技術文章參見《Java開發筆記（序）章節目錄》