@JamesR 这是一个常用的术语 - -

免息免手续费分期付款

一次性处理的话，用

$1 get=$5$9$13 uid=$3$7$11 op=$4$8$12

替换

^\s*(\d+)\s+(uid=(\d+)|op=(\d+)|get=(\d+))\s+(uid=(\d+)|op=(\d+)|get=(\d+))\s+(uid=(\d+)|op=(\d+)|get=(\d+))\s*$

（$ 是匿名捕获组，^$ 是行开头结尾而不是列开头结尾）

如果你的正则表达式引擎不支持大于 9 的匿名捕获组，使用不捕获组（这样恰好 9 个）或者使用命名捕获组。

更安全的方式是枚举 3! 种可能的排列写成正则表达式。

“我知道对于程序员这一行，代码网上随便 copy ”

亚洲人问号

不理比较简单，谁也不是上帝，很难评判观点的正误。一般只谈事实的正误就不会有问题。

@wobuhuicode 十几年前的网站没有 responsive 和这个配色😷而且应该更浮夸一些

@ghostheaven 比如你可以用 WSL 在 NTFS 分区的同一个目录下创建名字只有大小写不同的文件（夹）。

注意，你这样做会导致用 Win32 API 访问这个文件（夹）产生不必要的麻烦，所以不要用 Win32 访问之，用 WSL，或者用 WSL 清理掉实验现场。

@think2011 没有实战经验……居然还能这搞？（我以为收割器能计算 innerText 之类的）那你怎么做链接呢？ href=mailto 怎么做呢？

@sneezry 现在还是 2017 年

VBS 掩面逃跑（我用一个 VBS 清除 PS ReadLine 的历史记录。

@MrFireAwayH 认识，但我想不到我和他怎么和英国研究生联系在一起（毕竟都是本科

取决于你怎么设计这个系统。

大多数账号系统都是大小写保持、大小写不敏感的。

不过你会遇到一些恶心的问题，比如“大小写不敏感地相等”这件事情很模糊，你需要指定一个 locale。

……改换 Linux 也会有 Linux 的问题，谁身上没几个洞呢？

@idler

并不是“主动销毁”吧，我觉得只是“忘记”了？譬如密钥用完之后你一重启，那就跪了？既然黑客放出毒株的时候还留了那个“滚键盘域名”的后门，我觉得黑客搞传输密钥的逻辑可能没有特别小心，不小心弄丢密钥也是可能的。

@klesh

前一个问题：可以通过一开始取较大的 gap 避免，没说 id 必须是连续产生的；还有一种方法是准备另一个排序的 column，然后修改那个 column 以便以后按照“好”的顺序返回结果。（吐槽：行政区划这点数据还犯不着纠结这个问题，而且行政区划已经是有限层的问题了，不需要用这种组织形式存储。）

“前端不应关心后端如何存储数据，后端不应关心前端如何展示数据”

这个和你说用 A 不是矛盾的么？按照这个想法，A 和 B 都没有天然的优势，因为 A 是按照前端想要展示的方式准备数据，B 是按照后端立刻就可以得到的格式准备数据。

或者可能是我对“展示”的理解和你不同？在我看来数据以一个特定的逻辑形式存储出来（例如按照某种对象的形式）已经算是“展示”了，最后出现在屏幕上的方式不重要，因为从数据的逻辑存储形式到人可以通过不同的介质（常见的：屏幕、声音、编程）。或者说我认为前端和后端对接的部分是 model，而不是 view / view model，前端可以自己把 model 变成别的 model、view model。

如果把“展示”理解为打印到屏幕上，那前端和后端之间的 gap 可太大了……

但是我觉得没有理由要在本地加密密钥吧……

一个说法（出自微博 萌娘百科更新姬，但是该微博已经删除）是病毒会把密钥通过 tor 传输给服务器，但是因为被墙了，所以加密完成后就会导致密钥永远丢了？

@ghostheaven NTFS 里面当然可以在同一个文件夹下同时存在 a 和 A。

注意 Win32 API 大小写不敏感不等同于 NTFS 大小写不敏感。

类比：NTFS 上可以存储叫 con 的文件，不代表你可以用 Win32 API 访问那个叫 con 的文件。

此外即使只考虑 Win32 这个问题也不是因为 Win32 大小写不敏感导致的，因为 Win32 是 **大小写保持、大小写不敏感** 的，你可以通过 Win32 获取一个文件的准确名字。

@binux 然而似乎没有什么好的策略用于存储层数任意的树。当然题主给的这个例子里面层数是有限的。

@klesh 所以我说如果 pid < id 且按照 id 升序返回那就不会有问题啊。

@klesh @coderfox 为什么有根树的森林就一定要是递归的样式？有根树的森林不可以是符合一个约束的父亲数组存储？

@anheiyouxia 你确定关机安装失败之后会重启么……？

A 方案怎么分页？每次重新返回整个链条？

如果可以保证 pid < id，那么用 B 显然可以很简单地处理分页。

另外如果数据出现不一致（譬如有环），如果用 A 会更容易导致后端崩溃，如果是 B 那么后端很难崩溃。毕竟，一个顾客心肌梗死和一个商店塌了相比，还是商店塌了更可怕一些。

还有另外的考虑：如果分级的层数是固定的，那么你的 model 可以变化为固定深度的，那应该用 A。