不要自己发明概念，就是标准的无填充 aes-256-ecb 而已
echo -n "This is a secret" | openssl enc -aes-256-ecb -nopad -K 746869735f6d7573745f62655f6f665f33325f627974655f6c656e6774682121 | xxd -p

用合适的工具去做合适的事，既然是 json 结构，就要用 json 的方式去处理，使用正则表达式属于歪门邪道，会有很多很多的特殊情况，比如 value 里面有个转义过的双引号怎么办，就算你不断地针对每一种特殊情况去打补丁，最后这个正则表达式也会变得复杂无比

@Buges
@ysc3839
所以我说这个误解是多么的典型，因为会犯这个错误的人不少，类似的问题随便动动手就能搜到一大把
https://stackoverflow.com/questions/3391242/should-i-hash-the-password-before-sending-it-to-the-server-side
你一直在说撞库，请问防止撞库的手段是传输 hash 吗？不是，是存储 hash ，而传输 hash 的行为大大降低了存储 hash 的意义，极端情况下降为 0 ，你可以继续坚持自己的观点并在实际项目中使用前端 hash 并传输，但是麻烦告知下这样的项目地址以供避雷

@Buges 我从来没有否定存储 hash ，我否定的是前端 hash 并传输，你举的例子恰恰又一次证明了我的观点，如果全世界都前端 hash 并传输(假设在不加盐的前提下)，存储 hash 变得毫无意义

@Buges 前端 hash 是安全问题中最最最典型的一个只知其一不知其二而导致的误解，首先要知道之所以后端存储 hash ，目的是防止被脱裤后泄露密码，但是如果使用方式是前端 hash 并传输，那么脱裤者根本就不需要关心密码明文是什么，此时的 hash 就等于明文，使得后端存储 hash 变得形同虚设

@ershierdu 是不太大，也就 6670903752021072936960 种而已:doge:

@sunny352787 你自己再想想

@sunny352787 左移操作等于 x2 和大小端存储之间没有任何联系

点进来之前的我😏
点进来之后的我🥲

mutex

@icyalala 这几个统统都不是编程术语，而是数学术语

SIGTERM

@justfindu 这个类比不合适，因为水和电的成本是和产出量正相关的，而数据不是

@bigbyto 是的，口误了

语法糖是可替代的，也就是说你可以选择不使用语法糖，而直接写等价的别的语句来达到同样的目的
而语法是不可替代的，没办法在不使用该语法的情况下改为其他等价的语句

假如兼容了的话会违背自反性，即 a.equals(b) == b.equals(a)

忘了在哪看到的一个理论，公司倒闭的前兆之一就是开始抓考勤

你看不懂是因为里面出现了大量的数学名词及概念，不用深究，如果确实感兴趣的话可以去请教数学专业的人，我简单说下粗浅的理解，可能不准确，以专业人士的结论为准
整个这一段在说的就是 natural ordering 这个全序关系里的一个商构成一个等价关系，并且这个等价关系需要和 equals 构成的等价关系保持一致，至于关系、等价关系、关系的商这些就不展开了，去翻离散数学的书吧
说人话就是，x.compareTo(y) == 0 iff x.equals(y)

参见我在 https://v2ex.com/t/820095#reply6 里的回答
正则表达式不是万能的，只能匹配正则语言，而非正则语言中最经典的一个例子就是成对的括号
自己老老实实用个栈来做吧，比正则表达式简单多了