用UE的人都會覺得16進制顯示文件灰常方便。為啥捏？當你要對文件加密、轉碼、編碼的時候，蹦出一堆01二進制看著都會頭大。畢竟十六進制顯示文件簡短方便。至少中考高考時塗過卡吧，1+2+4+8能算明白是幾吧。當然，那些中考和高考都能把1248碼都塗錯的童鞋們，一看就知道它們果斷與程序猿這個“神剩”的職業無緣哈……
因為之前試著參加過科普創新大賽，當時做的咚咚是把文件以字節流讀入，並轉化成二進制、四進制、十六進制字符串，然後刷的一下子輸出到控制台。再根據每個位的值，分別以2色、4色、16色的矩陣顯示。寫這個的目的是為了用攝像頭識別，然後再還原成字節流寫到文件裡。這個程序設計是兩個蛋疼的事實雜交出的產物——1.要求不通過任何介質和USB設備傳輸文件；2.zxing和QRCode有時會找不到二維碼(QRCode更容易出錯)。大家可以試試這個題目，用攝像頭或者揚聲器發送接收文件，看誰傳得快，題目確實蠻有意思的呢。
當然，最重要的部分是進制轉化了，讀入文件的字節流byte 8位，用兩個16進制顯示。因為可能會遇到byte轉int後為補碼的情況，所以最好先統一成正數，方法其實很簡單啦，一個與運算就搞定！
代碼如下：
int result = bytes&0xff;
別小看這個語句，其實這個語句很有意思的。仔細想想，為神馬加了個0xff就變成正數呢？0xff每個位都是1，那與運算不就等於沒變化麼？哼哼，之前還真有人這麼問過我，如果真有這樣的問題，那就是java基礎不牢固了。byte的范圍是-128~127，不是0~255，所以嘛,像byte b= -42;這樣的賦值肯定不能用byte b= 214;來替代了。
弄出這個，轉成N進制字符串就不是啥難事了。仔細想想，是不是有個熟悉而又陌生的類直接就帶這個功能呢？沒錯，就是用Integer來實現！但是先別急，用它之前，還得對這個int搞點小動作。
代碼如下：
( bytes & 0xff ) + 0x100
知道這是為什麼？這個就是+256啊，只是為了看得直觀些，就是前面加上一位。因為你得到的int轉成String的話很可能只有一個位，也就是byte轉16進制時丟了一位，那整個程序豈不就全錯位了？安全起見，還是先統一成三位吧。
你可以試試這個看看所有byte變16進制後的輸出
代碼如下：
public static void main(String[] args) {
for (int i = -128; i < 128; i++) {
byte b=(byte)i;
System.out.println( Integer.toString( ( b & 0xff ), 16));
}
}
看到這裡，你會不會想：你怎麼這麼笨呢？for循環裡的int為什麼不改成byte，不就省了一行代碼了麼，多大的便宜啊！可以呀，你試試呗，反正我是不會去試的……
所以，最後把byte轉化成二位16進制的代碼是
代碼如下：
Integer.toString( ( bytes & 0xff ) + 0x100, 16).substring( 1 );
對於2進制，4進制，8進制，都是一個道理，我就不舉例了。一句代碼就實現了，很神奇吧……
接下來就是用矩陣晶格一幀幀顯示文件，用攝像頭拍下識別顏色，再轉換會字符串，並反饋個顏色讓對方知道識別完了好換下一張圖……如此循環，直到矩陣晶格顯示文件已經結束。這部分代碼我就不貼出來了，整個過程可以靠豐富的想象力YY出來吧……
然後是字符串轉回字節流，這就是簡單活了
代碼如下：
(byte)Integer.parseInt(string, 16)
連位運算都不用，直接就出結果，把它們放到字節數組裡，用FileOutputStream的write反復的寫就可以了！別忘了關閉輸入輸出流哈
