s='HELLO|*.py'
IFS='|' read -ar arr <<<$s

『 declare -p arr 后输出』
declare -a arr=([0]="HELLO" [1]="*.py")

假设按行分割，不要求按顺序输出的话：

sort a b | uniq -u > c

手机充电后，还会用电池的电吗？

@LeegoYih 这数据量小，可能都缓存至内存了也说不定

有试过每张表的 B+树三 /四 /五层高（视行记录长度的不同，可能分别能容纳几千万、几百亿、几十兆行记录）时，俩 /仨表 join 的耗时差异吗？

@LeegoYih 数据库范式是有点理想化，

所以，若有性能（你 join 多一个表，肯定性能差些）、分库分表难 join 等实际问题，你会妥协地加入『部门 ID 』至『用户表』吗？

就再打一两周试试呗，反正要耗的精力不像五笔那么大

@LeegoYih 数据库新手说下看法，有不对的请指正


这是另外一种什么范式吗？


以前学过的数据库范式说，

1. 每个字段都必须是不可再分割的原子数据项，不能是集合、数组、另一行记录等

2. 其他字段必须完全依赖整个主键组（如：用户部门表『「用户 ID ，部门 ID 」，用户名，省份名』，用户名只依赖用户 ID ，省份名不依赖任何其他字段，故不符）

3. 非主键不依赖其他非主键（如：学生表『「学号」，学院 ID ，学院名称』，学院名称依赖学院 ID ，故不符）

然而实际出于性能、分库分表难 join 等原因，总会冗余一些字段


回到你的回复，你说 用户表『「用户 ID 」，……，部门 ID 』不妥，

1. 部门 ID 业务不依赖 用户 ID （是说违反第二范式？但感觉实际上是依赖的？用户所属部门？）

2. 或用户可所属多个部门（部门 IDs ？但这违反第一范式？）


总的看起来，感觉你像是在说违反了数据库范式

所以，若有性能（你 join 多一个表，肯定性能差些）、分库分表难 join 等问题，你会妥协地加入『部门 ID 』？

@LeegoYih 即使一对多关系，也『不应该直接关联另一个实体』嘛

怎么感觉有的在说数据库的设计，有的在说 API 的设计……

@lmshl 懂的，都用递归下降了，肯定可以支持递归文法嘛

上条回复我是说，你当前代码里，没有用到递归文法，所以应该是三型文法

仅从『是否匹配』角度说，是可用『正则表达式』描述 你的文法 的（每个文法的结果处理函数就算了）

@lmshl 瞅了瞅，没用过 scala ，只能大概看得懂

这是扩展了自带正则库的文法规则，其递归下降去匹配？

int 、bool 、double 、string 是词法分析，其余是语法分析？（感觉全说成是语法分析也无不可？）

全部是三型文法？（因为没有递归？如：options ::= "options" ":" (options_tuple ("," options_tuple)* | options)）

也是高度依赖 tuple 有明确不同于其他文法的规则（要是 {options: opt1: val1, opt2: val2, label: user_id} 就完蛋了）


估计上游不好好用 json 库，自己手动拼接去了，真的是搞事情

@wizardyhnr 能用 100% 冗余度 代替原文件吗？否则出现所有备份各损坏一部分，咋办

@kerrspace 根据 @wizardyhnr #3 所说，利用 par2 （类似 winrar 冗余校错）写个小脚本，来实现：

（对于 A 盘任意文件 D:/path/src_file ，应对应于 a 盘中的 E:/path/src_file.par2 冗余校检文件）

1. src_file.par2 不存在，则自动生成（ 50% 冗余度？允许 < 50% 错误？）

2. src_file.par2 上次访问 /修改时间已超过 30 天，则校检一次（并自动修复错误），并更新访问 /修改时间

3. src_file 不存在，则删除 src_file.par2

效果会好吗？

@kerrspace 假如一个压缩包内容是 ABC ，A 盘内容变成 BBC ，a 盘内容变成 ABB ，咋办？

@FYFX 我这方面没啥经验。但总感觉，你的『解析 options 的值』这个步骤，适合放到语法分析中


如你所说，『在碰到下个<keyword, 关键字>或者<}, 右花括号>之前……』，

即『在碰到两种 Token 之前……』？


另外，放到语法分析中，后续若想解析成 下列形式，也更容易些？（可扩展性强些？）

1. {"options": {"1": "a:aa", "2": "b:bb"}}

2. {"options": ["1:a:aa", "2:b:bb"]}


好吧，如果放到词法分析中，要打算用啥方法解析 Token 呢？

NFA/DFA ？应该不够用吧（也就是，三型文法的正则表达式，无法胜任了）

LL/LR/SLR/LALR ？（我瞅瞅去）

@FYFX 词法分析有上下文相关的吗？

@lmshl
@ericmzhu
@ysc3839
@FYFX

编译原理新手求问，你们咋写词法和语法分析呢？


比如下面这条，你们词法分析结果是啥呢？

{options:1:yes:tag-info,2:no:tag-danger}


这样吗？

<{,左括号><options,关键字><:,冒号><1,数字><:,冒号><yes,字符串>……<},右括号>


那你们文法咋写呢？

1. 键值对 ::= 关键字 ":" 『？？？』

2. 多个键值对 ::= 键值对 | 键值对 "," 多个键值对

3. 对象 ::= "{" 多个键值对 "}"

@sutra 我看 regex101 说，golang 的正则不支持断言，条件子组也不支持。你这是用了第三方库是嘛

每匹配一个字前，都要看看后面的是否是一个关键字，我总觉得性能消耗会大一点

另外，我老怀疑你『?!:』写错了……

@morri 你试试这个：

\s*"?(options)"?\s*:\s*"?((?:[^,]*?:[^,]*?:[^,]*?,?)*)"?\s*([,}])|\s*"?(\w+)"?\s*:\s*"?(.*?)"?\s*([,}])

『要求』

1. options 键的值，为若干个以『,』分隔的 value:label:class （每个字段都不包含『,』）

2. 其他键的值不包含『,』『}』

3. 头尾裹上『"』后（若已有则不裹）仍符合 json 字符串规范