请特别阅读 @依云 的答案。分析上游代码和文档,这才是真正坚不可摧的力量。
看似跨平台但本质动作仍然平台有关的操作,真的千万少用。Python的跨平台特性,遇到了情况也惯坏人……
在磁盘上跳来跳去真不安全,还是整批进整批出的把握。
大量随机读写查询的需求,好好调动个高层的工具(数据库等)。
同仁们,误入歧途了啊!!!别在ASCII的文件上这么深入的追究编码问题啊!!!
我试了一下,果然爽翻:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
f = open(r"C:\Users\776\test.txt","w+")
# 注:w+ truncates the file - 因此文件无论存在与否,结果一致
f.write('hello')
print(f.read())
f.close()
# 结果不贴了,同样不忍直视,传送门:http://paste.openstack.org/show/61806/
我没有深入的究其原因,不过大概能猜到理由是什么:文件的指针位置。
open()以w+模式开启了一个读写模式的文件,由于是w,所以文件被废弃清空(truncate),此时的文件内容为[EOF],开启时的指针为0。此时如果做read(),则Python发现指针位置就是EOF,读取到空字符串。
在写入hello之后,指针的位置是5,文件在内存中是hello[EOF]。
但看起来read()的时候,Python仍然去试图在磁盘的文件上,将指针从文件头向后跳5,再去读取到EOF为止。
也就是说,你实际上是跳过了该文件真正的EOF,为硬盘底层的数据做了一个dump,一直dump到了一个从前文件的[EOF]为止。所以最后得到了一些根本不期待的随机乱字符(这里根本不是编码问题造成的乱码!)。
(看起来似乎还暴露了一些以前文件的内容呢,C:\Anaconda\神马的 :D)
解决这个问题,你需要在读文件之前,用file对象的flush()方法,将已修改的文件内容可靠写盘:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
f = open(r"C:\Users\776\test.txt","w+")
# 注:w+ truncates the file - 因此文件无论存在与否,结果一致
f.write('hello') # 此时指针=5,内存内容=`hello[EOF]`
f.flush() # 此时硬盘内容=`hello[EOF]`
print(f.read()) # 此时指针=5,正好在[EOF]上,正确输出''
f.seek(0) # 指针归0
print(f.read()) # 正确从头读出全部内容'hello'
f.close()
这并不是完美的解决方法,因为我总觉得flush()应该是真正决定写盘之前才做的,而不是read()一次就flush()一次。read()似乎还是优先读取内存缓冲区更有道理。
但总之至少猜测到了一个原因,并一定程度解决问题,更好的方法有待补充吧?