空间？空间是最不值钱的。4T 硬盘搞起。
比起这个，干净整洁、管理成本低、冲突概率低、索引速度快。。。各种收益都比空间要大得多。
而且，一般人手里也不会有那么多份项目在活跃，不活跃的项目尽情打包、存档、放服务器好了，并不占（你的）空间。

什么你是搞 python 的？ python 依赖环境才多大啊，我居然浪费这么多口舌解释空间的价值问题。
我还以为你搞 java、搞 node 呢！

对不起可能您与我司的数据分析岗不太匹配，
但我依然发掘到了您的一些闪光点，只要是人才，我们求贤若渴。
请问您是否会考虑我司的销售岗？

宽于律己，严于待人。

大项目用小框架——核心紧凑，结构稳定，定制化灵活。
小项目用大框架——练习，探索，充分预留发展空间。

大人用小碗——慢食，轻食，避免过饱，优雅，从容。
小人用大碗——长身体，男子汉气概，方便折腾。

如果装逼需要，类似的扯淡道理我可以编出一箩筐。
————————————————————————————
另外我还发现一个现象，一句话，不管它携带了什么信息，只要携带以下不同寻常的特征：
数字浓缩：五讲四美三热爱、八荣八耻、一带一路
对仗：空谈误国、实干兴邦
押韵：要想富，少生孩子多种树、人有多大胆，地有多大产
反常理：宁要社会主义的草，不要资本主义的苗

那它就是一个成功的 slogan，容易被不明真相的群众相信、传播、解读、崇拜。至于其价值，倒是次要了。
————————————————————————————
话说回来，有没有业界调查，关于现实项目中
大项目用大框架，小项目用小框架
vs
大项目用小框架，小项目用大框架
的统计对比数据？

没想到楼里这么多拿 demo 说事的。。。不是自我阉割就是法盲。
白天讨论别人“擦边球”，晚上抓起枪就突突突的吃鸡，知不知道杀人是死罪？双标玩的溜。
其实他们都未必意识到自己双标了，而仅仅是“赌博会被抓碰都不要碰”和“这么多人吃鸡都没事”两个浅层事实简单相加的结果。

@just1 所以说法律认定标准在哪里？要件有哪些？
主观上是否以营利为目的，客观上是否具有聚众赌博、开设赌场、以赌博为业的行为。对于虽然多次参加赌博，但输赢不大，不是以赌博为生活或主要经济来源的；或者行为人虽然提供赌场、赌具，本人未从中渔利的，都不能认定赌博罪。其中情节严重的，可按《治安管理处罚法》有关规定处理。

不要老爷说什么就低头认怂，好歹争一口合理合法。

中午是什么？不都是 12 点吃外卖吗？

首先，先搞清楚你把数据加载到内存后打算干吗。
这坨数据就是比你内存大，和格式无关。哪怕它是再精简不过的 bin 格式，哪怕我用 c，都无法解决 8G 内存读取 800G 数据的矛盾。
唯一的出路，就是根据数据格式和需求确定解析和计算模式，部分解析，部分计算，分治然后汇总。

建议的几种读取方式：
1，SAX 了解一下，事件流驱动的 xml 解析思路，搬到 json 上毫无问题。
2，切割原 json 文件，给它补上恰当的开始、关闭符来确保结构。
3，自己实现解析器，最 low 的状态机实现起来很简单的。然后一边解析一边处理一边丢弃。
4，如果 json 数据有某种特征，预处理一下。（比如结构体其实不复杂元素也不多，但里面有个字段的值超大，那么先文本处理 json，把这个字段抽取出来形成外部文件，json 内只留个文件名索引）其实很多超大数据集要么结构简单只是数据条数多，要么条数不多但单条比较大，很容易做针对性处理。

sep 参数支持正则表达式。如果你的分隔符和字符串能用某种正则来做区分，那可以把单纯的"|"字符替换成正则来做分割。
第二个问题，这确实不是合法字符啊。最好是搞清楚来源是什么。很有可能是读时就读错了，最好解决掉。否则这行数据有可能是脏的。

居然还有这么多法盲觉得这是件好事。。。如果你们觉得知识传播是好事只是因为朴素善良而忽略了版权侵权的话，那篡改名字呢？如果那个名字就是你自己呢？

site design / logo © 2018 Stack Exchange Inc; user contributions licensed under cc by-sa 3.0 with attribution required. rev 2018.5.30.30566

SO 有明确版权申明，甚至根本不用找，就在页脚。每一页都有。

解释一下，by 表示必须提到原作者，sa 表示如果允许修改原作品（例如翻译），那么必须使用相同的许可证发布，with attribution required 作为一个补充 SO 有专门的页面阐释 https://stackoverflow.blog/2009/06/25/attribution-required/。

给个 echo 接口放出 url 来给大家看看可能更清楚。

在 markdown 语法层面，##和==等效。我更喜欢##，从 h1 到 h6 很统一很方便记忆很有逻辑美感。
在渲染层面，h2 和上文有没有亲密接触，真的是 css 的事情，和 md 一点关系都没有。

@huclengyue 战术层面的勤劳掩盖了战略层面的懒惰。任何语言里额外转一次 string 都是体力活，但好在不用动脑呀。
相反，选择自带库不是懒惰，这是聪明的偷懒，因为脑力都耗费在设计上，耗费在方案选择上了。就算自带库不能满足需求（比如 js 自带 json 解析不能满足 long 需求）依然花力气去找轮子而不是造轮子。有现成的谁不爱用呢是吧。

你要这么想：输入是 bin，要求输出是 string，用什么？当然用 base64 一步达成。
urlencode 输出是 string，但输入也是 string，并不符合你的场景需求，你还得为它做一步转换准备好入参。预先从 bin -> string 过程中，必然会引入新的因素：编码。
再说一下字符编码。并不是任意一个 bin 都能转成对应的 string 的。很多编码方式都有它自己的规则，例如 utf-8，对于 n 字节的符号（ n > 1 ），第一个字节的前 n 位都设为 1，第 n + 1 位设为 0，后面字节的前两位一律设为 10。因此很容易构造（遭遇）一个非法的 bin 序列在转换时报错。还有，转换后的码点是不是一个合法字符？这是由码表说了算。码表上不存在的，有可能就作为非法字符忽略或者显示为框或者问号。
假设第一步转换凑巧没出错，还得考虑第一步转出特殊字符，第二步 urlencode 时会不会正常处理。例如\0、\r、\n。。。毕竟它的设计并不是计划用在这种场合。

塞到 json 里用 urlencode 首先就错了。base64 足矣。
其次，问题的原因是编码。如 2 楼所言。

1，不谈 json，绝大部分持久化协议都有类型系统。为什么？可能这些协议设计者规范制定者都是傻子吧！
2，json 大数字导致 js 解析失败的问题，是怪 json ？我扔个 20 位的字符串你 js 真的就能按 long 处理了吗？我扔个 2000 位的呢？我扔个 10^20 的大数字字符串把你内存撑爆了你是不是还是怪 json ？冤有头债有主，https://www.npmjs.com/package/long 了解一下。要搞科学计算的，请自己实现大数字的解析和计算。别死抓着系统 json 解析库不放，却怪字段类型。
3，类型错误导致异常的同学，硬生生通过消灭错误的根源解决了错误。你们真厉害，跟 zf 一个处理思路。那值错误问题呢？想个办法也消灭掉？参数个数问题呢？变长参数嘛！参数顺序问题呢？调用时用字典传参写明 key/value 对嘛。参数名拼写问题呢？我编不下去了。。。不过我想聪明人应该能解决，办法总比问题多嘛！

——以上是恶搞，以下是正经分析——

其实还有一点是非常重要的：信息抹除。原接口设计和数据 /参数持久化是携带了类型信息的，被硬生生抹除了。
接口 a 需要一个 int，传了个"0"，
接口 b 需要一个 string，传了个"0"，
接口 c 需要一个 bool，传了个"0"。
他们默默做类型转换的时候，揣摩通透服务端的意图了吗？万一服务端真的 bug 了，就输出了一个错误的类型，你能察觉吗？
这是信息抹除带来的第一个问题：错误被掩盖。
第二个问题可能是某些人习以为常的：文档上说入参均为 string，但其实具体实现中会对他们做对应的转型操作。转错了程序当然没法正确执行。这使得人们更依赖所谓的文档，却直接丢弃了语言 /协议 /架构 /方案自身的自描述和自检能力。“最好的文档就是代码本身”这句话的价值不是为懒得写文档找借口，而是真正的金玉良言。
第三个问题随着第二个问题而来，文档缺失和过期大概是实际项目中的常态，信息抹除所带来的额外信息恢复工作就变成了一项困难的事，增加更多不必要的成本和风险，以及团队沟通成本、技术管理成本。

那么为什么很多“给别人用的接口”反而倾向于这样设计呢？容错性表面上能稍微好一点，而额外带来的风险和成本又不必自己承担。典型的就是给第三方用的接口、给其他部门用的接口、给其他团队用的接口。后端给 app 扔个这样的接口，不必沟通，不必争论，暂时性的增加了双方的幸福感。有种让他在团队内部同一项目内声明一堆 Object... args 的方法？怕不被自己人打死。

说白了，这就是懒惰+短视+自私的人性抉择。