file.seek()方法引出的文本文件和二进制文件问题
1|0问题的起因
菜鸟教程上有一段关于file.seek()方法的讲解,先简短描述一下seek()方法:
- seek(offset, whence)方法用于移动文件读取指针到指定位置
- 参数offset--开始的偏移量,也就是代表偏移的字节数
- 参数whence--可选,默认为0。0表示从文件开头算起,1表示从当前位置算起,2表示从文件末尾算起
- 返回值:该方法没有返回值
2|0实例
文件runoob.txt的内容如下:
循环读取文件的内容:
运行一下发现报错了:
3|0分析原因
3|1文本文件和二进制文件
这要要从文本文件和二进制文件说起了。
从广义(物理意义)上说,二进制文件包括了文本文件,因为计算机最终存储的是二进制文件,所以物理意义上两者就是一回事,但从狭义(逻辑)上来说,两者存储的方式又有所不同。
文本文件又叫ASCII文件,这种文件在磁盘上存放时,每个字符(8个bit位)对应一个字节,用于存放对应的ASCII码,例如:
ASCII 码 00110101 00110110 00110111 00111000
| | | |
5 6 7 8
共占用了4个字节,ASCII文件可在屏幕上按字符显示。
二进制文件,是按二进制编码存放文件的,如5678的存储方式为:00010110 00101110,只占用2个字节,二进制文件虽然也可在屏幕上显示,但其内容无法读懂。C系统在处理这些文件时,并不区分类型,都看成是字符流,按字节进行处理。 输入输出字符流的开始和结束只由程序控制而不受物理符号(如回车符)的控制。 ,因此也把这种文件称作"流式文件"。
3|2读写的区别
在读取文档时,python认为0x1A(26)是文档结束符(EOF),所以有时使用"r"读取二进制文件时,可能会出现读取不全的现象,如:
二进制文件中存在如下从低位向高位排列的数据:7F 32 1A 2F 3D 2C 12 2E 76
如果使用'r'进行读取,则读到第三个字节,即认为文件结束
如果使用'rb'按照二进制位进行读取的,不会将读取的字节转换成字符,从而避免了上面的错误
在写入文档时,写入'\n',windows操作系统会隐式的将'\n'转换为"\r\n",再写入到文件中;读的时候,会把“\r\n”隐式转化为'\n',再读到变量中,而二进制文件是非解释性的,一次处理一个字符,并且不转换字符。
3|3r+和rb+
- "r+"是打开一个文件用于读写。文件指针将会放在文件的开头
- "rb+"是以二进制格式打开一个文件用于读写。文件指针将会放在文件的开头
3|4python3.4的官方解释
To change the file object’s position, use f.seek(offset, from_what)
. The position is computed from adding offset to a reference point; the reference point is selected by the from_what argument. A from_what value of 0 measures from the beginning of the file, 1 uses the current file position, and 2 uses the end of the file as the reference point. from_what can be omitted and defaults to 0, using the beginning of the file as the reference point.
意思是,为了改变文件对象的位置,可以使用f.seek(offset, from_what)方法。最终位置等于参考点位置加上偏移量,参考点是由from_what参数决定的。from_what有三个值,0代表文件的开始位置,1代表使用当前的位置,2代表文件的末尾位置。from_what参数省略时,默认是0。
python官方文档也给了一个实例:
In text files (those opened without a b
in the mode string), only seeks relative to the beginning of the file are allowed (the exception being seeking to the very file end with seek(0, 2)
)
在文本文件中,只有在文件开头(即from_what默认是0时)进行偏移是被允许的。不允许在当前所在位置(from_what=1)和文件末尾(from_what=2)时进行偏移。
现在回头看看我们的第一个代码和报错信息,发现我们的读写模式用了"r+",我们的文件是文本文件,在使用fo.seek()时,将from_what的值设置为1,所以报错了。
4|0延伸
如果我们把读写模式改为"rb+",以二进制的方式进行读写,那么是不是就可以了,确实可以,但不容忽视的一个小问题是,二进制文件不会对windows下的换行(\r\n, 0x0D 0x0A)进行转化的,我们看到的结果将是:
5|0参考
https://blog.csdn.net/timberwolf_2012/article/details/28499615
https://www.zhihu.com/question/19971994
https://docs.python.org/3.4/tutorial/inputoutput.html
http://bbs.fishc.com/thread-60449-1-1.html
https://www.cnblogs.com/kingleft/p/5142469.html
https://www.cnblogs.com/xisheng/p/7636736.html
https://bbs.csdn.net/wap/topics/350127738
https://www.cnblogs.com/pengwangguoyh/articles/3223072.html
https://blog.csdn.net/seu_xuxueqi/article/details/621904
http://www.xuebuyuan.com/367184.html
__EOF__

本文链接:https://www.cnblogs.com/my_captain/p/8904036.html
关于博主:评论和私信会在第一时间回复。或者直接私信我。
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
声援博主:如果您觉得文章对您有帮助,可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?