A股上市公司传智教育(股票代码 003032)旗下技术交流社区北京昌平校区

 找回密码
 加入黑马

QQ登录

只需一步,快速开始

© 彭嘉聪 黑马帝   /  2012-1-10 01:00  /  2269 人查看  /  2 人回复  /   0 人收藏 转载请遵从CC协议 禁止商业使用本文

本帖最后由 彭嘉聪 于 2012-1-16 22:48 编辑

就是19天14的那个视频,对于myread()返回int类型时,提升类型且补0的操作。
问一下这个是对于mp3文件才是这样处理还是对每一种文件都是如此?

还有解答下这样操作的好处(最好给自己的见解)。

2 个回复

倒序浏览
凡是必须用用字节流读取的都应该如此,避免了取到的字节和你设定的返回条件相同就不继续读取了。老师写的只是一个原理,源码不是那样,更复杂,只是道理差不多。
回复 使用道具 举报
      这个主要是针对字节类型的文件的,像mp3,这样的字节类型文件,在内部都是以二进制形式存储的。
这样的话它的第一个字节就可能是11111111------>-1,当你read第一个字节的时候,就可能读出-1.
-1这个数据使while循环里的判断条件为false,循环就不执行了,也就读不出数据了。读不出来,自然也谈不上写
这样就等于没有复制成功。
    解决的办法:让byte类型提升为int。即:11111111----->11111111-11111111-11111111-11111111-------->(-1)
这也就是为什么myRead()返回的是Int 类型。但是这样提升后,int类型的32位都是1,十进制还是-1,还没有完全解决。
那我们既想保证原数据的原样性,又不让它出现-1,于是就让这个32位全1的int型数据前24位补0,保留低8位为1.
能做到这一点的可行方法是让它&00000000-00000000-00000000-11111111,这样就原来的byte 类型的-1就最终转成了int类型的255,
避免了要读的数使while()为false而导致一开始就不能读或还没复制完循环就结束的情况发生。
     提醒一点:我们复制的是byte类型的文件,可是我们读的时候把它转成了Int型,这样读出来的数就比原数多点4倍的空间。可是我们复制
完发现,文件大小没有变化。那是因为read()方法是将byte提升为Int,而write()方法在复制的时候又自动的只取int类型32位的低8位,也就是有效位。
相当于又把Int降为byte,然后再写入文件。
回复 使用道具 举报
您需要登录后才可以回帖 登录 | 加入黑马