这个还有一个好处，就是跨平台。
在 2011-09-14三的 00:26 +0800，Earthson写道：
> 其实也是文本啦，而且紧凑程度还不如直接的文本。
> XML和JSON的优势是有层次和结构，适合结构化的数据
> 但是一般需要这种结构的应用并不是那么多的（当然，web应用是例外哈，因为数据实在是太多了，不像系统或者软件的配置文件和一些简单信息）
复杂一些的配置文件，也都XML化了。
> 2011/9/13 An Yang
>
> > 在 2011-09-13二的 12:21 +0800，Earthson写道：
> >
> > > 对数据来说，二进制存储的方案会更紧
其实也是文本啦，而且紧凑程度还不如直接的文本。
XML和JSON的优势是有层次和结构，适合结构化的数据
但是一般需要这种结构的应用并不是那么多的（当然，web应用是例外哈，因为数据实在是太多了，不像系统或者软件的配置文件和一些简单信息）
2011/9/13 An Yang
> 在 2011-09-13二的 12:21 +0800，Earthson写道：
>
> > 对数据来说，二进制存储的方案会更紧凑。比如一个8位整数，二进制用4个字节，文本需要8个字节。但是，对普通字符来说，其实两者是差不多的。
> > 二进制保存结构比较复杂的文件，是需要各种头信息的，这会额外占用空间。
> > 手
在 2011-09-13二的 12:21 +0800，Earthson写道：
> 对数据来说，二进制存储的方案会更紧凑。比如一个8位整数，二进制用4个字节，文本需要8个字节。但是，对普通字符来说，其实两者是差不多的。
> 二进制保存结构比较复杂的文件，是需要各种头信息的，这会额外占用空间。
> 手动操作二进制文件需要额外维护这些信息，相比之下，文本文件的维护简单太多了。
> UNIX的哲学是鼓励使用文本文件的。
现在的趋势是XML和JSON化了。
>
> 2011/9/12 tvdbukrf inuyasha <4entertri...@gmail.com>
>
> > 握爪~
对数据来说，二进制存储的方案会更紧凑。比如一个8位整数，二进制用4个字节，文本需要8个字节。但是，对普通字符来说，其实两者是差不多的。
二进制保存结构比较复杂的文件，是需要各种头信息的，这会额外占用空间。手动操作二进制文件需要额外维护这些信息，相比之下，文本文件的维护简单太多了。
UNIX的哲学是鼓励使用文本文件的。
2011/9/12 tvdbukrf inuyasha <4entertri...@gmail.com>
> 握爪~我就是这么想所以有此一问~
>
> On Monday, September 12, 2011, An Yang wrote:
>
> > 读文件的速度，和获
握爪~我就是这么想所以有此一问~
On Monday, September 12, 2011, An Yang wrote:
> 读文件的速度，和获取文件中信息的速度，完全是两个概念。
>
> 在 2011-09-12一的 22:52 +0800，tvdbukrf inuyasha写道：
>
> > 据说因为二进制比较紧凑而且储存形式跟内存中的一样所以确实快些？
> >
> > On Monday, September 12, 2011, An Yang wrote:
> >
> > > 读什么文件，速度都是一样的，但处理里面的内容，就会因内容而异了。
> > >
> > > 在 201
好吧……
可读文件格式读入确实比二进制要慢，这是由于这其中存在一个转换的问题，我不太会python，不过c++在32位系统下一个long
int是4字节，写入二进制的时候就直接将内存中的这四个字节写入文件……而写入可读文件格式则还需要将这二进制转换成文本，这样不仅仅浪费了空间（32位最大允许42亿左右的数据，42亿换成可读文件格式，需要10个字节，而二进制用4个字节保存），还降低了效率。因为转换需要时间，我用一个for循环来转换一个int到可读文件格式需要循环10次（每次转换10之后再整除10），不知道要取多少次内存（虽然肯定远远不止，不过估计是10次吧），而写入一个int的二进制值只需
读文件的速度，和获取文件中信息的速度，完全是两个概念。
在 2011-09-12一的 22:52 +0800，tvdbukrf inuyasha写道：
> 据说因为二进制比较紧凑而且储存形式跟内存中的一样所以确实快些？
>
> On Monday, September 12, 2011, An Yang wrote:
>
> > 读什么文件，速度都是一样的，但处理里面的内容，就会因内容而异了。
> >
> > 在 2011-09-12一的 20:39 +0800，tvdbukrf inuyasha写道：
> >
> > > 编的一个程序一直都是用别的程序导出的可读文件作为数据文件，
据说因为二进制比较紧凑而且储存形式跟内存中的一样所以确实快些？
On Monday, September 12, 2011, An Yang wrote:
> 读什么文件，速度都是一样的，但处理里面的内容，就会因内容而异了。
>
> 在 2011-09-12一的 20:39 +0800，tvdbukrf inuyasha写道：
>
> > 编的一个程序一直都是用别的程序导出的可读文件作为数据文件，最近有人建议我直接把那个程序的数据文件给unpack效率会更高。
> > 但为什么高又不甚清楚，Google一番后也没找到什么答案，因此冒昧的在这提问下，虽然跟ubuntu没啥关系就是~~
>
额~谢谢您的回复，json、pickle这些我倒是略知一二。
不过我说的是数据的读入与操作的问题诶~
On Monday, September 12, 2011, Shellexy Wang wrote:
> 别理会那些建议，
>
> 要人类读的话直接 json 模块 dump 出来就是了
>
> 自带 json 模块用 json.dumps(obj, ensure_ascii=0, indent=4) 这参数会输出可读性非常好的格式化文本
> 要兼顾些速度的话就尝试用 cjson 模块。
>
> 而如果不需要人类读的话，不妨直接用 pickle / cPickle 模块 dump 出对
别理会那些建议，
要人类读的话直接 json 模块 dump 出来就是了
自带 json 模块用 json.dumps(obj, ensure_ascii=0, indent=4) 这参数会输出可读性非常好的格式化文本
要兼顾些速度的话就尝试用 cjson 模块。
而如果不需要人类读的话，不妨直接用 pickle / cPickle 模块 dump 出对象
（版本 0 是文本格式，版本 1 是紧凑的二进制格式
2011/9/12 tvdbukrf inuyasha <4entertri...@gmail.com>
> 编的一个程序一直都是用别的程序导出的可读文件作为数据文件，最近有
读什么文件，速度都是一样的，但处理里面的内容，就会因内容而异了。
在 2011-09-12一的 20:39 +0800，tvdbukrf inuyasha写道：
> 编的一个程序一直都是用别的程序导出的可读文件作为数据文件，最近有人建议我直接把那个程序的数据文件给unpack效率会更高。
> 但为什么高又不甚清楚，Google一番后也没找到什么答案，因此冒昧的在这提问下，虽然跟ubuntu没啥关系就是~~
>
> 比如用python
> 我想如果是可读文件，直接就能拿来用了，比如readline起来挺方便的。
>
> 如果是二进制文件，读取起来确实是比可读文件快，可是似乎没太多办法
编的一个程序一直都是用别的程序导出的可读文件作为数据文件，最近有人建议我直接把那个程序的数据文件给unpack效率会更高。
但为什么高又不甚清楚，Google一番后也没找到什么答案，因此冒昧的在这提问下，虽然跟ubuntu没啥关系就是~~
比如用python
我想如果是可读文件，直接就能拿来用了，比如readline起来挺方便的。
如果是二进制文件，读取起来确实是比可读文件快，可是似乎没太多办法去操作，最简单的四则运算都觉得挺麻烦，似乎也没啥module？得搞清楚数据结构后再struct.unpack。
这样下来难道后者就一定比前者快么？
声明本人编程水平算是入门中的入门，所以问题弱智
12 matches
Mail list logo
