Orien Daily
- 📚 「〜にあたって」不是万能正式表达：它和「〜際に」差在哪？
很多人写技术文档或研究计划时，喜欢把所有“在……时”都写成「〜にあたって」。这就容易过头。比如「実験結果を確認するにあたって」看起来很正式，其实别扭。因为「〜にあたって」不是单纯表示“做某事的时候”，它更常用于，带一点“郑重展开”“以此为契机”的感觉。相反，如果你只是说操作时、处理时、查看时，通常该用「〜際に」或「〜とき」。
区分时抓一个边界就够了。「〜にあたって」强调的是前置节点，像“在部署前、在提交论文前、在系统迁移前”；后面往往接准备、方针、注意事项、确认事项。它不适合套在很日常、很细碎、可重复的动作上。所以「ファイルを開くにあたって」很怪，但「本システムを本番環境に導入するにあたって」就很自然。跟它相近的「〜際に」则更中性，只表示“在……之际/当……时”，场景广得多，操作说明、注意提示、用户手册里尤其常见。
看几个能直接套用的句子。
本番環境へデプロイするにあたって、依存関係と環境変数の整合性を事前に確認する必要がある。
在部署到生产环境之前，有必要事先确认依赖关系和环境变量的一致性。
脆弱性診断を実施するにあたって、対象範囲と通信制限の条件を明確にしておくべきだ。
在实施漏洞诊断之前，应该先明确目标范围和通信限制条件。
ログを解析する際に、個人情報に該当するデータが含まれていないかを確認してください。
在分析日志时，请确认其中是否包含个人信息数据。
如果你把第三句也写成「解析するにあたって」，语法不算错，但味道变了，会像是在说“正式开展日志解析这一工作之前”；如果你只是想表达“解析时注意一下”，那就该老实用「際に」。
💡 記憶ポイント： - 🔐 反序列化为什么危险：对象不是数据，代码也会跟着进来
很多人第一次接触反序列化漏洞，会觉得它只是“把字符串还原成对象”而已，听起来像普通的数据解析。但危险就在这里：如果一种序列化格式不只是保存数据，还保存“对象类型”和“构造方式”，那程序在反序列化时就可能顺手执行一串你没打算执行的逻辑。Java 的readObject、Python 的pickle、PHP 的unserialize都出过这类问题，本质不是库“脆弱”，而是你把“不可信输入”当成了“可信对象”。
为什么会发生？因为开发者脑子里常有个错觉：来自数据库、缓存、消息队列、Cookie、文件上传里的内容，看起来像内部格式，就默认安全。可攻击者只要能控制这段序列化数据，就能伪造一个对象图，让程序在恢复对象时自动调用魔术方法、钩子函数或者 gadget chain。于是反序列化不再是“读数据”，而变成了“按攻击者指定的方式跑代码”。现实里常见后果包括远程命令执行、任意文件读写、权限绕过，甚至只是一个签名校验缺口，也足够让攻击者把本地组件串成武器。
真正实用的防法也不是“多加几个黑名单类名”。黑名单是补丁思维，迟早漏。更靠谱的做法是别用会恢复任意对象的格式处理外部输入，能用 JSON、MessagePack 这种纯数据格式，就别把类实例直接扔出去再捡回来。如果历史包袱太重，至少要做三件事：第一，反序列化前做严格完整性校验，比如带密钥的签名，而不是裸 base64；第二，限制可反序列化的类型白名单；第三，把危险逻辑从对象的构造、析构、魔术方法里拆出去，别让“恢复对象”顺手触发副作用。说白了，输入应该只是数据，不该拥有决定程序控制流的权力。
🧪 你在审计一个老 Web 系统，发现它把登录态存在 Cookie 里，值是 base64 后的 PHP serialize 字符串。开发者说“攻击者看不懂内容，而且 Cookie 里没有命令执行代码，所以问题不大”。这里最关键的风险点是什么？unserialize()
💡 核心记忆：只要外部输入能被还原成“对象”，你就得假设它可能把程序控制流一起带进来。 - 📸 @SapporoBeer
山本選手が勝利を重ねるたびに、グラスの☆も増えていく限定デザイングラス。
10勝目を記念して、特別バージョンをご用意しました⚾️⭐️
▼キャンペーン詳細はこちら
▼これまでの由伸と乾杯MOVIEもアーカイブ👇
https://lnky.jp/lMBbfMZ #黒ラベル #山本由伸 #getastaryoshinobu
原文 #MLB日本選手 - 📸 @30R9gmaMUy3guDJ
大谷翔平選手の
第5打席はセカンドゴロ
本日はここまでノーヒット
試合は8回9-4でフィリーズがリード中
①空三振②二ゴロ③見三振④申告敬遠⑤二ゴロ #大谷翔平 #ドジャース
原文 #MLB日本選手 - 🔑 并查集为什么几乎总比你手写连通性判断更对
并查集（Union-Find）解决的是一个很朴素的问题：一堆元素不断被“连起来”之后，你想快速知道两个元素现在是不是属于同一组。它看起来像是个小技巧，真正厉害的地方在于设计思路很干净：它根本不关心这组里具体长什么样，也不关心连接路径是什么，只维护“谁和谁最终属于同一个代表元”。这就是它快的原因——它只保存判断连通性所必需的信息，别的都不存。
如果你自己硬写，最容易走进一条烂路：每次合并两组时，把整组元素重新扫描、重编号，或者用图搜索临时判断连通。这样在数据量一大、操作一多时，很快就会慢得离谱。并查集的做法更像是偷懒到极致：每个集合选一个根节点，元素只需要一路找到根，就知道自己属于哪一组；合并时，也只是让一个根指向另一个根。核心操作只有两个，find 找根，union 合并根。
但裸的并查集还不够好。真正让它“几乎等于 O(1)” 的，是 path compression 和 union by rank/size。path compression 的意思是：你查一次根，就顺手把沿途节点直接挂到根上，下次再查就更短。union by size 的意思是：小树挂大树，别反过来。为什么这样设计？因为所有性能问题本质上都来自树太高。你不控制高度，find 就会退化成一长串父指针追踪，最后跟链表没区别。
这里最容易踩坑的地方，不是原理，而是实现细节。第一种坑是把 union(x, y) 写成 parent[x] = y，这几乎总是错的，因为 x 和 y 可能都不是根，你是在随手改中间节点，结构会变脏。正确做法是先找 rootX 和 rootY，再决定谁挂谁。第二种坑是以为 path compression 会改变“集合内容”，其实不会，它改的是树形结构，不改连通关系。第三种坑是把并查集拿去做删除边、撤销合并这类操作；这就超出它的舒适区了，因为它擅长的是只增不减的连通性维护，不擅长回滚和动态拆分。
这东西为什么在算法里反复出现？因为很多问题的本质不是“图怎么走”，而是“关系是否已经连上”。Kruskal 最小生成树要它，是因为它只关心加一条边会不会形成环；账户合并、朋友圈、岛屿连通、网络分组也要它，因为这些问题都在反复问同一句话：这两个东西现在是不是同一类。你一旦看清问题本质只是“分组归属”，就别再上来就建整张图然后 DFS/BFS，那个数据结构已经重了。
🧪 课后一题：有 6 个元素，初始各自独立。依次执行 union(1,2)、union(2,3)、union(4,5)、union(3,5)。最后 1 和 5 是否连通？集合一共有几个？
💡 易混淆点：并查集只能高效回答“是否同组”和“合并分组”，它通常不能直接告诉你两点之间的具体路径，更不适合处理删除关系后的连通性变化。 - 每日推歌已发送
- 🎵 Nocturne No. 2 in E-Flat Major, Op. 9 No. 2 — Frédéric Chopin
专辑：Chopin: Nocturnes · 4:33
钢琴像贴着耳边慢慢铺开，主旋律一出来就带着克制的起伏，装饰音像呼吸一样轻，越听越能感觉到那种温柔里的微微闪光。它不是把情绪一下子推满的古典名曲，而是用很细的触键和流动感，把夜曲写成了能反复停留的私密片刻。
🔗 Spotify · #推歌 #古典SpotifyNocturne No. 2 in E-Flat Major, Op. 9 No. 2Frédéric Chopin, Daniel Barenboim · Chopin: Nocturnes · Song · 1982 - 📸 @CFADnFpiqAnFf0T
八段先生から
｢今のままでは七段は無理やなぁ～｣
｢力が入り過ぎ,打とう,,,打とう,,,としている｣
悪い癖が出ました。
数年ぶり稽古をお願いできた八段先生。府警で現役の頃、全日本で常連だった先生です。名前を憶えて頂いただけでも緊張するのに😖
次、頑張ります
七段先生の面抜き胴 ↓ #剣道
原文 #剣道 - 📸 🔍 黄礼志 via @yejigallery ×2
yezyizhere instagram update
Error 500 (Server Error)!!1500.That’s an error.There was an error. Please try again later.That’s all we know. #YEJI
原文 #黄礼志
