This media is not supported in your browser
VIEW IN TELEGRAM
📸 @koukichi1129 ×2
おい、俺よ。
なぜそこでそんな引き胴が決まると思ったんだ…
どうせなら、そのその返し技みたいなのをたくさん打ってくれい… #剣道 #小池自治会剣道部 #試合近いのに練習不足
原文 #剣道
おい、俺よ。
なぜそこでそんな引き胴が決まると思ったんだ…
どうせなら、そのその返し技みたいなのをたくさん打ってくれい… #剣道 #小池自治会剣道部 #試合近いのに練習不足
原文 #剣道
Lua 的表达式解析器为什么不用 LR？
编译原理课上教的 LR 分析器，当然是经典。但打开 Lua 的源码，你会看到
思路很直白：给每个 token 绑定两个优先级，一个「左绑定力」（left binding power），一个优先级比它高时才继续往下吃「右绑定力」（right binding power）。解析器从左到右扫描 token，遇到操作符时，比较当前操作符的左绑定力和栈顶操作符的右绑定力——左边强就先归约，右边强就先递归。二元运算、一元运算、函数调用、下标访问，全都能塞进同一套框架，不需要额外的规则表或状态机。
Lua 的实现尤其精简。
为什么 Pratt Parser 在实践里这么受欢迎？V8 的 parser、Rust 的 parser、甚至 GCC 后来也逐步转向手写递归下降。原因之一是错误信息——手写递归下降可以精确控制在报错位置给出有意义的提示，而 LR 生成器的报错出了名的难读。原因之二是扩展性——加一个新运算符？插入一行
但它也有代价。Pratt Parser 本质上是递归下降，无法直接处理左递归文法。比如 这样的规则，必须先消除左递归再实现。此外，优先级的全序假设意味着所有运算符必须能排出一个严格的优先级序列，遇到 Python 那种比较运算符链式调用（ ）就得额外处理裸括 。而且这类手写 parser 的正确性没法像 LR 那样由形式化工具自动验证，全靠人肉 review 和测试。
下次再看到编译课上那张 LR 状态转换表的时候，可以顺手翻一下
#CS
编译原理课上教的 LR 分析器，当然是经典。但打开 Lua 的源码，你会看到
lparser.c 里处理表达式的是一套完全不同的打法——Pratt Parsing，也叫自顶向下算符优先解析。思路很直白：给每个 token 绑定两个优先级，一个「左绑定力」（left binding power），一个优先级比它高时才继续往下吃「右绑定力」（right binding power）。解析器从左到右扫描 token，遇到操作符时，比较当前操作符的左绑定力和栈顶操作符的右绑定力——左边强就先归约，右边强就先递归。二元运算、一元运算、函数调用、下标访问，全都能塞进同一套框架，不需要额外的规则表或状态机。
Lua 的实现尤其精简。
subexpr 函数收一个 limit 参数，表示"当前能接受的最低优先级"，递归时把操作符的右绑定力作为新的 limit 传下去。binop 和 unop 的处理逻辑加在一起不到 80 行，整个表达式解析就搞定了。没有冲突、没有归约/移进的抉择，更没有用生成器吐出几千行 C 代码。为什么 Pratt Parser 在实践里这么受欢迎？V8 的 parser、Rust 的 parser、甚至 GCC 后来也逐步转向手写递归下降。原因之一是错误信息——手写递归下降可以精确控制在报错位置给出有意义的提示，而 LR 生成器的报错出了名的难读。原因之二是扩展性——加一个新运算符？插入一行
case 就行，不用重新生成再排查 shift/reduce conflict。但它也有代价。
E → E + E | ida < b < c下次再看到编译课上那张 LR 状态转换表的时候，可以顺手翻一下
lparser.c，看看真实世界的 parser 是怎么写的。#CS
HTTP Request Smuggling：一个请求，两种解读
前端代理和后端服务器对同一个 HTTP 请求的边界判断不一致——这就是 Request Smuggling 的全部内核。听起来简单，但它能造成的后果远比想象中严重。
场景是这样的：很多部署架构在用户和源站之间放了反向代理（Nginx、HAProxy、CloudFront 等），代理收到请求后转发给后端。关键在于，代理和后端如何判断"这个请求在哪结束"？有人靠
最经典的变体是 CL-TE：代理认
防御层面，最根本的做法是让代理和后端使用完全相同的解析逻辑——但现实中这并不容易保证。更务实的策略包括：代理层拒绝同时包含 CL 和 TE 头的请求、对后端连接禁用 keep-alive 复用、以及配置代理将
思考题：如果一个架构中代理和后端都对 CL 和 TE 做了严格校验、拒绝歧义请求，但引入了第三层 WAF，这三方之间的解析差异是否可能产生新的缝隙？
#Security
前端代理和后端服务器对同一个 HTTP 请求的边界判断不一致——这就是 Request Smuggling 的全部内核。听起来简单，但它能造成的后果远比想象中严重。
场景是这样的：很多部署架构在用户和源站之间放了反向代理（Nginx、HAProxy、CloudFront 等），代理收到请求后转发给后端。关键在于，代理和后端如何判断"这个请求在哪结束"？有人靠
Content-Length，有人靠 Transfer-Encoding: chunked。如果两者对同一份请求的解析结果不同，代理认为这是一个请求，后端可能认为这是两个——或者反过来。攻击者利用这个缝隙，把自己的payload"塞进"下一个用户的请求里，伪装成那个用户的身份操作。最经典的变体是 CL-TE：代理认
Content-Length，后端认 Transfer-Encoding。攻击者构造一个边界模糊的请求，后端会把"溢出"的数据当成下一个请求的开头。后果包括绕过访问控制、窃取其他用户的 session token、投毒 Web 缓存。2019 年 Salesforce 的研究团队披露，亚马逊、Azure 等主流平台都受影响，整个行业狠狠地震了一次。防御层面，最根本的做法是让代理和后端使用完全相同的解析逻辑——但现实中这并不容易保证。更务实的策略包括：代理层拒绝同时包含 CL 和 TE 头的请求、对后端连接禁用 keep-alive 复用、以及配置代理将
Transfer-Encoding 标准化后再转发。#Security
「より」だけじゃ足りない時、学術書はどう書くか
論文やレポートで「AよりもBのほうが…」と書きたい場面はよくある。「より」で事足りることも多いけど、尺度が一段上がったことを強調したい時、「〜にもまして」という表現が効く。読み方は「にもまして」。意味は「〜よりもさらに」。例えば「語学力の重要性は昔日にもまして高まっている」のように使う。昔より今がさらに上を行っている、というニュアンスが「まして」一語で立ち上がる。
気をつけたいのは、比較の基準が名詞であること。「昔」や「以前」のような時間名詞と相性がいいし、「父母にもまして子を愛する人はいない」のように人にも使える。ただし動詞や形容詞をそのまま前に置くのは不自然で、そういう時は「〜のにもまして」との形にする。じゃあ次の文、どこがおかしいか。「彼の成績は去年にもまして良かった」—実はこれ、問題なし。去年が時間名詞だから。「彼が頑張ったにもまして結果が出た」—これは??「頑張ったことにもまして」なら正しいが、動詞節を裸で置くと変??。
学術文章でこの表現を使うと、「単なる比較ではなく、格段の差がある」という著者の判断が響く。論理の説得力を一段上げたい時、覚えておいて損はない。
#日本語
論文やレポートで「AよりもBのほうが…」と書きたい場面はよくある。「より」で事足りることも多いけど、尺度が一段上がったことを強調したい時、「〜にもまして」という表現が効く。読み方は「にもまして」。意味は「〜よりもさらに」。例えば「語学力の重要性は昔日にもまして高まっている」のように使う。昔より今がさらに上を行っている、というニュアンスが「まして」一語で立ち上がる。
気をつけたいのは、比較の基準が名詞であること。「昔」や「以前」のような時間名詞と相性がいいし、「父母にもまして子を愛する人はいない」のように人にも使える。ただし動詞や形容詞をそのまま前に置くのは不自然で、そういう時は「〜のにもまして」との形にする。じゃあ次の文、どこがおかしいか。「彼の成績は去年にもまして良かった」—実はこれ、問題なし。去年が時間名詞だから。「彼が頑張ったにもまして結果が出た」—これは??「頑張ったことにもまして」なら正しいが、動詞節を裸で置くと変??。
学術文章でこの表現を使うと、「単なる比較ではなく、格段の差がある」という著者の判断が響く。論理の説得力を一段上げたい時、覚えておいて損はない。
#日本語