没想到楼里这么多拿 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 的方法？怕不被自己人打死。

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

塞一个实例里：实例挂了不就都挂了吗？
塞一个集群里：集群挂了不就都挂了吗？
塞一个机房里：机房挂了不就都挂了吗？

任何策略都有收益和代价，并不存在一定对的策略更不存在完美无缺的策略。看你自己选择了。

白天开会，晚上干活，这是日常。
思考？所有暗时间。
这下你知道程序员为啥爱加班不爱社交了吧。。。/023

什么都可以魔改啊。。。这个有限制吗？

cs 专业课了解一下。#58 有列。

其实说实话，就算以上都了解，很多野蛮生长的人还是比不上科班出身。为什么？
并不是那些专业课的原因，专业课几乎都是基础，离现实很远。有帮助，但帮得略显有限略显过时。
根本差异还是在人，在人的学习方法和学习速度。
面试、招聘过很多科班和野草，概率上来说，科班就意味着这人的学习能力足以让他轻松通过本科硕士的课程。进入工作以后虽然几乎还是白纸，快速学习能力能让他们迅速吸取知识并抓住本质还能融会贯通形成体系。
概率上来说，野鸡学校、培训班、初中毕业的人更容易出现学习困难的征象，成长缓慢，被动学习，他们一路就是这么磕磕碰碰凑凑合合走过来的，工作以后就指望能脱胎换骨一日千里？

所以，根本上还是人的问题。

人的差异有两方面：大脑的差异，这是先天的。有的人就是思维敏捷。方法和习惯的问题，这是后天的。人家有独特的有效的学习习惯和技巧。
先天的不用考虑，杞人忧天毫无价值。而且绝大部分人的努力程度和终身成就之低，低到根本用不着拼天赋的地步。所以我们还是只考虑后天因素好了。

关于学习方法，这个也是可以学习可以练习的，和野不野生没关系。网上有很多介绍，更系统更全面更科学，我就不班门弄斧了。只针对性提几个建议：
1，强烈的决心。lz 看起来是有的。
2，合理的计划。lz 看起来没有。
3，适合的方法。例如看视频是远小于看书的，效率低，被动，不利于思考。

有了合适的方法和习惯（发动机），追上所谓科班生也就 1 年时间而已。再往后，你跑的可比他快了。