This topic created in 3832 days ago, the information mentioned may be changed or developed.
我有一个文件, ls 显示的大小是 1000k, 然后我 readline 读, 把每行的 sys.getsizeof(line)加起来, 最终结果却跟 ls 显示不一样, 请问我哪里弄错了呀?
 |
1
Mush OP 用 len 也不对......怎么都对不上
|
 |
2
MarioLuisGarcia Nov 2, 2015
getsizeofline 得到的是 python 字符串的长度吧。
python 一个空字符""的长度都有 37 ，因为它是一个对象，带了很多方法。 |
|
3
Mush OP @MarioLuisGarcia 这个我 get 到了, 搞错了这个函数的意思.....但是用 len 的话也是对不上的....
|
 |
4
ChanneW Nov 2, 2015
ls 是实际占用空间吧。
操作系统不会给文件正好分配文件实际大小那么大的空间的。 |
|
5
MarioLuisGarcia Nov 2, 2015
@Mush 如果你用 len 的话，首先得确定 len 返回来的数值单位是什么，然后你确定 ls 返回来的单位是什么？两者计算方式有无不同。然后再做对比。
|
 |
6
aisk Nov 2, 2015
用 len 来获取的话，跟你的字符串编码方式有关，推荐不要用字符串来保存你的数据。
|
是合作方用文本保存的数据, 一个文件好几个 G..... |
8
Mark3K Nov 2, 2015
使用 len 计算字符串长度，如果字符串编码是 ASCII 的话一个中文算 2 个，如果是 UNICODE 的话就算 1 个
|
1 |
12
Mush OP @aisk 恩, 谢谢. 但我的具体情况是, 我并没有解压这个压缩文件, 我是用 tar -tvf 拿到解压后文件大小, 然后用 subprocess.Popen(["zcat", log_file],stdout=subprocess.PIPE)进行读取. 不过我具体测试了一下, 计算出来的文件大小差别不大, 可以满足我做个读取进度的需求, 所以暂时先这么用, 哪天有空了再仔细研究下.
|
 |
13
Freedom1 Nov 3, 2015
不要用 ls 算文件大小，用 du -h,本人亲测 ls -lh 和 ll -h 算出的文件大小不正确，用 du -h 比较接近
|
Select Language