Orien Daily








📚 「にあたって」不是万能“在……时”:它只用于正式起点,不用于普通同时动作
很多人写技术或学术日语时,会把“在做某事时”一律写成「〜にあたって」。这东西一旦乱用,句子会显得很重,而且会错。因为「にあたって」不是普通的“当……的时候”,它带的是“面对一个重要节点,要开始做准备、说明方针、采取措施”的味道,常见于研究启动、制度实施、系统迁移、发表前说明这种正式场景。
它最容易和「際に」「にあたり」混在一起。先说区别。「際に」只是中性地说“在……之际 / 在……的时候”,范围很广,买东西、登录系统、提交材料都能用,不自带郑重感;「にあたって」则强调“这件事本身是一个关键起点”,所以后面常接 検討する、確認する、整備する、説明する、留意する 这种动作。至于「にあたり」,基本就是「にあたって」的更书面版本,公告、通知、规章里特别常见。反过来,如果你只是想说“运行程序时出错了”“登录时需要验证码”,那就别硬上「にあたって」,用「際に」或者更直接的「とき」就够了。
比如研究和工程文档里,这样写是自然的。研究計画の策定にあたって、先行研究との違いを明確にする必要がある。制定研究计划时,需要明确与既有研究的差异。
本番環境への移行にあたって、アクセス権限と監査ログの設定を再確認した。正式环境迁移前,对访问权限和审计日志设置进行了再次确认。
論文を投稿するにあたり、実験条件と再現手順を付録に整理した。投稿论文前,把实验条件和复现步骤整理进了附录。
但下面这种就不自然:× このスクリプトを実行するにあたって、エラーが出た。这里不是“面对重大节点做准备”,只是单纯“执行时出错了”,应该写成 このスクリプトを実行した際に、エラーが出た。或者更干脆一点,このスクリプトを実行すると、エラーが出る。
💡 記憶ポイント:遇到「にあたって」,先问自己一句:这里是不是“在一个正式、重要的开始节点上,准备做后续动作”?如果是,就能用;如果只是普通的“当……时”,多半该换成「際に」。关键记忆点可以压成一句:。
🔐 JWT 算法混淆:为什么“验签了”还是会被伪造
很多人第一次接触 JWT(JSON Web Token)时,会把注意力全放在“这个 token 有没有签名”。问题在于,真正危险的地方常常不是“有没有签”,而是“你拿什么方式去验这个签名”。JWT 头里有个alg字段,用来声明签名算法,比如HS256或RS256。如果服务端天真地相信这个字段,攻击者就可能把原本应该用非对称密钥校验的 token,改成对称算法去处理,最后把公开的公钥当成 HMAC 密钥来伪造签名,这就是经典的算法混淆。
这事会发生,不是因为 JWT 天生不安全,而是因为很多库早期设计得太“灵活”了。开发者把“支持多种算法”当成功能,结果把“由谁决定算法”这个控制权交给了用户输入。用户发来的 token 头里写什么,后端就按什么验,这就等于把门锁类型也交给访客自己选。只要系统同时支持RS256和HS256,又没有把某个 issuer、某条认证链路、某个 key 和固定算法绑定起来,攻击面就出来了。
现实里的防法也不复杂,但必须硬。第一,服务端不要从 token 里“学习”该用什么算法,而是自己预先写死允许的算法,比如这个服务只接受RS256,那看到别的算法直接拒绝。第二,key 和算法要绑定,RSA 公钥就只能走 RSA 验签,绝不能被拿去做 HMAC。第三,别把“支持多算法”当兼容性优点,认证链路越单一越安全。第四,选成熟库时看默认行为,凡是允许alg=none、自动降级、自动猜算法的,都是坑。
🧪 你在审一个登录系统,设计文档写着“统一使用 JWT”。代码里验签函数直接读取 token header 里的alg,然后从配置里取一把 public key 去验。开发者说“反正 public key 本来就是公开的,没问题”。这里最致命的风险是什么?algHS256
💡 核心记忆:认证里最危险的不是没校验,而是把“怎么校验”这件事交给攻击者决定。
📸 @dodger_ticket
こちらが今日配布のリング💍
由伸くんをゲット😊❗️💙 #大谷翔平 #山本由伸 #佐々木朗希 #ドジャース #ドジャーススタジアム #ドジャスタ #dodgers #dodgerstadium #ShoheiOhtani
原文 #MLB日本選手