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