最贊回答 / mmzpr5554321
正如你所說，byte只有8位，然后int有32位，所以byte轉(zhuǎn)換為int，int的前面24位是無意義的（就是跟轉(zhuǎn)換過來的值無關(guān)），所以0xff=0000 0000 0000 0000 0000 0000 1111 1111 & b可以保留后8位的數(shù)值，前面24位不管是0還是1都會為0不顯示。
2017-09-08
已采納回答 / 慕雪6201052
因為他過時了。該類童工了對文件的操作，包括寫于讀，與其他的IO類基本沒有多大的關(guān)系，是一個獨立的類。而最新的IO操作，分的特別詳細，包括輸入流，輸出流，讀與寫等等。不再是以前的單一類可以完成的。內(nèi)存映射，，差不多可以取代RandomAccessFile 了
2017-09-06
已采納回答 / 慕田峪1616461
如果是read(byte[] b)，若最后一次讀取的長度不及數(shù)組的長度，則后面的內(nèi)容會是上次讀取殘留的內(nèi)容；如果是read(byte[] b, int off, int len)，若最后一次讀取的長度不及數(shù)組的長度，則后面的會為空，解決了為什么用read(byte[] b)讀取產(chǎn)生的結(jié)果比原來多的問題
2017-09-04
已采納回答 / 慕粉2335383635
f是16進制數(shù)，ffffffc4 化為二進制就是1111 1111 1111 1111 1111 1111 1100 0100 ；0xff化為二進制是1111 1111；&是按位與，ffffffc4 & 0xff 時0xff高位補0, 最后得到的二進制數(shù)是0000 0000 0000 0000 0000 0000 1100 0100，轉(zhuǎn)化為16進制就是0xc4,高位的0忽略掉
2017-09-03
最贊回答 / 一五五一
ObjectOutputStream的實例調(diào)用writeObject(obj)方法時,虛擬機通過反射檢查對象的類是否實現(xiàn)Serializable接口,如果實現(xiàn)，則虛擬機內(nèi)部進行序列化操作，同時通過反射檢測類是否有writeObject方法,如果有則調(diào)用obj的writeObject方法，反序列化類似。我是這樣理解的，歡迎指正。
2017-08-27
最贊回答 / YI_F
引用woider所講的:使用緩沖字節(jié)流復(fù)制確實是最快的方式，但對于小文件10M以下的文件體現(xiàn)不出優(yōu)勢，對于百兆文件正確使用，時間可以控制到50ms內(nèi)。視頻中的緩沖字節(jié)流使用有錯誤，復(fù)制文件最快的做法是將批量讀取到的字節(jié)數(shù)組使用緩沖寫入到文件，在機器性能范圍內(nèi)字節(jié)數(shù)組越大越快。在循環(huán)寫入的過程中不需要使用flush，就像cwt8805說的，緩沖輸入流在關(guān)閉的時候會將所有緩沖區(qū)的數(shù)據(jù)全部寫入文件，使用flush刷新緩沖就失去了緩沖的意義。最后關(guān)閉IO流和文件流應(yīng)該在finally中關(guān)閉，否則IO異常時執(zhí)行不到...
2017-08-26
已采納回答 / 慕粉1927036099
一個a和b分別是一個字節(jié)，四次i是四個字節(jié)，但是又接著把i按int寫入，是四個字節(jié)，gbk編碼的中文是兩個字節(jié)，總共十二個字節(jié)
2017-08-18
最新回答 / 政政0213
過濾器是針對字符操作的，是為了防止編碼問題，通常網(wǎng)絡(luò)傳輸與本地文件尤其是txt.doc，數(shù)據(jù)庫導(dǎo)出表excel等時需要注意這些問題
2017-08-16
