/ 最近 .rdf 追記 設定 本棚

脳log[2025-11-23~]



2025年11月23日 (日) [AtCoder] 昨日は AtCoder Beginner Contest 433 があった。ABCD 4完だけど意外に耐えた。それで耐えられるレベルが情けない話。■A 問題 Happy Birthday! 4。最難関 A 問題来ました。なんもわからん。どっちが大きくてどっちが小さくてどっちがいくつずつ増えてどっちが早く大きくなるのか、なんもわからん。全探索でも許されるのはわかる。でも十分な範囲がなんも見積もれない。実行時間で区切れば 1000 万まではいける。でも 10000 で十分な雰囲気(!)も感じられる。ふわふわといつまでも雲を掴んでもいられないので6分時点でとりあえず投げて運を天に任せた。■B 問題 Nearest Taller。N が 20 万なら考えるけど N が 100 なので考えずに全探索。なんで A 問題がこうじゃないんだ。■C 問題 1122 Substring 2。1 と 2 の境界を全探索して、左右を調べる。高々全長の2倍しか調べないので愚直にやって大丈夫。■D 問題 183183。x と y の mod M が足してゼロか M なら f(x,y) が M の倍数。x の mod M がそのままの値ではない。y の桁数によって 1 から 10 桁まで持ち上げられる。10 から 100 億を x に掛けたものの mod を取る必要があるということ。数列 A の要素ごとに高々 10 通りの mod M なので予め集計しておく。■E 問題 Max Matrix 2。時間を使い過ぎないようにうまく情報を持って順番にマス目を埋めていくだけだと思った。最初の実装を完成させるのに1時間と6分かかった。時間を使い過ぎないようにうまくやれはしたけど、別の意味で時間を使い過ぎているし、WA が出てしまった。提出 #71168194 (WA×4/AC×26)。残り6分なのでランダムケースで考え漏らしやバグをを見つけることもできず終了。F 問題は読んでいない。


2025年11月20日 (木) ScanSnap S1500 を処分することにした。純正の消耗部品はもう手に入らないし、消耗部品でない紙送りローラー(4つ)が溶けてスキャンに支障が出ている。ネットで見かけたシリコンチューブを使った方法も試したけど、一時的な延命にしかならなかったし、安定しなかった。紙送りが差し支えると 1 mm の帯が 5 mm、5 cm に引き延ばされたような縦長の画像が出力される。あからさまだとすぐにスキャンし直せるけどあとで読んでいるときに1ページ2ページ横一線に入ったにじみに気がついてももう紙束がなかったりする。エラー率は 20 % から 1 % のあいだくらい。ベストな状態でもゼロにはならなかったし、ベストな状態が何か月も続くわけでもなかった。シリコンチューブはまだまだ十分な長さが残っているけども。あとは紙を差し込んでも全く吸い込まないことが頻繁にあって、パッドとローラーとシリコンチューブの隙間で何がどうなって空回りしているのかわからない。わからないままだましだまし機嫌を伺ってスキャンしてきたのがここ数年のこと。それより以前は角川文庫の紙質を特に苦手にしていた以外はそれなりにうまくいっていた。一度セットしたらあとは放置という具合にはなかなかいかなかったけど。15 年間で 708472 枚スキャンしたらしい (ScanSnap Manager による報告)。もう十分かな。■IX2500 を買うと決めた日がたまたま IX2400 の発売日で、今日まで様子を見ていたけど待ちきれなくて IX2500 を注文した。IX2500 を IX2400 と比較したときの自分にとってのメリットは USB ケーブルが省略できるということのみだけど、販売価格差が数千円なら IX2500 が安すぎるのでそれでいい。15 年前の S1500 の購入価格が 41000 円だったのだから、昨今の物価を考えると IX2400 で5、6万円、IX2500 で7万円でも良心的価格だったと思う。これは販売価格の話。IX2500 の最安は5万円からなので安すぎる。4万でも5万でも懐には痛いし1週間様子を見てきたのではあるけども。


2025年11月16日 (日) [AtCoder] 今日は estie プログラミングコンテスト2025 (ARC210)があった。■A 問題 Always Increasing。直前の要素からいくつプラスされている必要があるかという情報を管理しながらクエリをシミュレートする。実際の提出では増分ではなく数列の値そのものを BIT で管理して無駄に log を付けた。それにもかかわらず BIT だから累積和だからということで勘違いをして、N 番目の値を参照したら N 項の累積和が得られると思い込んで答えが合わなかった。21 分かかっています。■B 問題 Remove Median Operations。1回のクエリをシミュレートすることはできると思うんだけど、クエリ毎にシミュレーションを繰り返していては当然間に合わない。困ったね。先の問題をチラ見して追い返されたりしながら考えていると、数列 B を数列 A に放り込む操作はまとめて行ってもいいような気がしてきた。A と B を混ぜて小さい方から N/2 個、大きい方から N/2 個を取り出して合計したものが答えではないか。それの正しさは X から X の中央値を削除する代わりにマークを付けてシミュレートしていけばなんとなく(!)わかる。あとは昨日の ABC-E と同じように BIT で数と和を管理して答える。それだけのことがすんなりいかないんだな。小さい方から N/2 個と大きい方から N/2 個を得るのに左からと右からで添字を調整してごちゃごちゃするのが嫌で、ソート列を昇順と降順で2つ作って、データは2つだけどコードはコピペで済ませようとした。ところが座圧のためのデータは複製していなかったために結局添字の調整が必要になっていて、それに気がつかなくてデバッグに時間を取られた。#71013020 の 81 行目。Mn↔Mx の交換だけではダメで 77 行目では X[i] だったものを X[~i] にしている。こんな罠に初見でひっかからないはずがなく……。40 分かかっています。■C 問題 Fair Coin Partition。だいたいの答えは出た。最初にどんどん繰り上げていって、大きいコインから順番に M 人に配る。小は大を兼ね、逆はそうではないので、大きいコインを無駄にしないように最初にすべて繰り上げて大きいコインから順番に最大限消費していく。その次が問題。M 枚未満の半端なコインを今度は繰り下げていきたいのだけど、最初に持っていたコインより細かく砕くことはできない。何枚繰り下げることができるのか把握しきれなかった。


2025年11月15日 (土) [AtCoder] 今日はオムロンプログラミングコンテスト2025 #2(ABC432)があった。E までで C が一番難しかった!■A 問題 Permute to Maximize。逆順ソート。■B 問題 Permute to Minimize。昇順ソート……なんだけどゼロ始まりは許されない。正規表現でやろうとして5分かけてしまった。自分は Ruby の置換文字列フォーマットが好きじゃないんだよね。最初に JavaScript で学習したから後方参照(\1,\2...)とかぶっているのが気に入らない。それに文字列リテラルのエスケープ文字として \ が消費されてしまうことへの配慮がないのも問題。だから必ずブロックを与えてグローバル変数としての $1,$2... を参照するんだけど、忘れていました。■C 問題 Candy Tribulation。19 分かかった。ずっと手が動かなかった。大きい飴の数を最大化するというからまずは個数のすべてを大きい飴に寄せた。そこから総重量を揃えるために小さい飴に置き換えていく。その刻みは必ず Y-X ずつなので、まずは不可能なケースとして Y-X で割った余りがすべて同じでないといけない。最も個数が少なく従って最も軽い人の総重量に揃えられるのかな? 個数が多すぎるとできないけども。提出後も半信半疑でジャッジの進捗を見守っていた。WA が出て全く不思議がなかった。■D 問題 Suddenly, A Tempest。大きな海苔を縦または横にスパッと切ってずらす。それを最大で 14 回。2 の 14 乗でもそれほど大きくない。矩形の切断と移動をシミュレートして許されそう。矩形クラスを用意させられているあたりでもう実装が大変なんだけど、まだ後半パートがある。細かく刻まれた矩形の隣接判定と UnionFind がしたい。しかし組み合わせの総当たりは (1<<14)**2/2 > 1億3000万なので許されないと思った。刻まれた矩形の1枚1枚は重なっている部分がゼロのはずで、隣接のしかたは右辺と左辺もしくは上辺と下辺が1差で隣接している場合に限定できるので、X(Y) 座標で分類して Y(X) 座標でソートすれば総当たりの2乗ではなくソートの NlogN のオーダーで判定ができると思った。ところが自分は分類だけしてソートも尺取りもしなかったのでオーダーが改善しておらず最悪で ((1<<14)/2)**2 ≒ 6700 万の計算量で危なかったけど、45 ms で余裕だった (#70980315)。ギリギリの計算量で落とす意図はなかったみたい。■E 問題 Clamp。クエリ2の式の意味を理解するのに時間を要した。なるほど上と下をクリップするのねと理解した瞬間に問題名の Clamp が目に入って悔しい思いをした。式を読まずに Clamp の一語ですべてが伝われば早いんだけど、そういう順番での理解はありえないんだろうな。でも苦労してたどりついた結論が問題名に書いてあるっていうね。クエリ2に罠があります。l と r の大小関係に制約がありません。そういうときはクランプするのに min と max をとる順番に応じた定数になる。問題自体はいつもの BIT で和と個数を管理するやつ。お前 F 問題の常連ではなかったか。■F 問題 Candy Redistribution。N の制約が 20 以下と小さいけど何が難しいのかがわかっていません! たくさんの飴を持っているなら、自分か相手のすくなくとも一方の個数をちょうどにできる。あまりにも多くの飴が足りないなら、複数の人からかきあつめる必要がある。これはどちらも避けられない操作なので差はつかない。差がつくのは余りと不足がぴったり一致している二人のあいだで受け渡しを行うときで、1回の操作で2人が満足する。だからたぶん難しさというのは、たくさん持っている人がうまく分配することで、たとえば X 回の操作で自分を含む X+1 人が満足するケースをどのように実現するかだと思った。まるで見当がつかないので BFS をして経路を復元する方法を書いている途中で時間切れ。BFS のキーはソートして正規化したいけど並べ替えをしてしまうと操作列の復元が難しくなる(不可能ではなさそう)、というところで足踏みをしている。■順位表を見ると 86 分の遅遅5完でも意外に高くて 585 位だった。E 問題を 2294 人が通しているのに対して D 問題を通しているのが 732 人ととても少ない。自分では ABCDE で一番頭を使った C 問題を 4429 人が通しているのはちょっと信じたくない。もっと自分と同じように苦しんでほしかった。■■■D 問題ってもしかしてカットして倍々に増やしていくことってできない?(日曜の朝最初に頭に浮かんだこと) X カットと Y カットがそれぞれ n 回と m 回なら(n+m=N)、(n+1)*(m+1) が精々? 矩形の数が最大で 64 ? 総当たりでもなんでもやれば通るんだ?


2025年11月14日 (金) 20251016 の続き。パスキー。「認証情報のデバイスをまたいだ一元管理とオンライン同期は別の話であって、Google に一元管理させる一手はない」と書いていたこととちょっと関係する話。「「1Password」がWindows 11のパスキー管理ツールに、他デバイスとの同期も可能 - 窓の杜」 オンライン同期プロバイダーという仕組みをマイクロソフトが Windows に用意して、1Password がそれに対応したことで、認証自体は Windows Hello が行うけども、バックエンド部分(同期と、保管も?)を 1Password が担う形に。1Password の評価は保留するけども、他の、アルゴリズムで勝手にアカウントを BAN して何の応答もサポートも得られないという話が聞こえてくるところに自身のアイデンティティを預けるなどできようはずがないので、取り替え可能な仕組みは良いと思う。だけどね、やっぱりね、オンライン同期は余分なんよ。オプションなんよ。Windows の手を借りるのでも Android の手を借りるのでもいいけど、デバイスに認証情報を保存するのが一番で、その段階でオンラインのアカウントに出番はない。Android を使うのにログオンはしないし、Windows を使うのにログオンしているのはローカルアカウントだ。鍵を同期するためにネットワークに持ち出すときに初めてネットワーク上のアカウントと紐付けるのが順番だろうと思う。そして自分はそういう形のポータビリティは求めていない。パスワードをメモした物理メディアがなんぼマシか。他人の介入は不要。


2025年11月08日 (土) [AtCoder] 今日はトヨタシステムズプログラミングコンテスト2025(ABC431)があった。■A 問題 Robot Balance。頭でっかちはダメです。■B 問題 Robot Weight。N 種類のパーツを付けたり外したり。なんかせこい方法ないかなって考えて思いつかなかったから 01 配列を別に持ったんだけど、重さの値を -1 倍しながら足せば良かったんかな。■C 問題 Robot Factory。A 問題の発展。重いボディ K 個と軽い頭 K 個の一意な組み合わせ。これを実装するにあたり、ソート列から重い K 個と軽い K 個を取り出すメソッド(shift/pop)を取り違え、頭と体を比較する演算子の向きを間違えるのが自分です。■D 問題 Robot Customize。B 問題の発展。DP をしたいけど状態をどうするか。頭の重さに対して頭に取り付けたパーツとボディに取り付けたパーツの嬉しさの合計の最大を記録した。頭に取り付けなかった時点でそれはボディに取り付けることが決定しているのでその嬉しさを即座に合算してしまって総合的な優劣を比較すれば良い。しかしこれは TLE×3 だった。計算量を見積もってみると、N=500, sum(W)=500*500 のとき、ループ全体で 500 の3乗(=1億2500万)。頭の重さの最大が sum(W)/2 なのでざっくり半分にして 6250万。これは Ruby には厳しい。ここで見かたを変えて、ボディに取り付けた場合の嬉しさはただで手に入る嬉しさであり、頭に取り付ける場合は重さにハンデを抱えるけどボディに取り付けた場合の嬉しさにさらに嬉しさを付け加える行為だと考えた。そうするとボディに取り付ける場合の嬉しさは必ず得られるベースラインなのでいちいち計算して比較する必要がなくなる。頭に取り付ける場合の嬉しさはボディに取り付ける場合よりどれだけ大きいかで評価されるので、そもそもボディに取り付けた場合より嬉しさが低いなら頭に取り付ける理由がないとわかってループが省略できる。よく知らない用語を雰囲気で使って説明すると、2か所からもらう DP をしていたものが1か所からもらうだけで済むようになった。実際の計算量は入力の傾向に依存するような気もするけれど、これらでおよそ半分に時間が節約できて AC になった (#70786365)。他の言語では必要のない苦労だったかもしれない。入力の傾向に関係なく状態空間のサイズ(と遷移)に応じた決まった時間で答えが出るのが DP であるので、何をやってもそれは定数倍の改善か入力依存のアドホックな改善でしかない。■E 問題 Reflection on Grid。同配点の F 問題も一応読んだ。トポロジカルソート的な感じで場合の数を数えたいけど「徒競走」に比べて制約が大きすぎる。見込みがないと思って E 問題に専心した。その E 問題。重実装の気配がビンビンしています。それどころか実装に取りかかれない。これは頭を使う必要があるなと一度立ち止まって考えることにした。盤面のマスの数が多すぎるので1マス1マスああしてこうしてと試行錯誤することができない。1か所変更してみた結果青木君に光が届くかが即座にわかると仮定してみたら答えられるだろうか。たとえば初期盤面の経路の1マス目を変更して結果を見る。ダメなら1マス目はそのままにして2マス目を……。これの何がダメか。盤面の外に飛び出さない限りおよそどんな経路を選んでも青木君にはたどりつく。ただし操作手順が増える。操作手順の少なさが問われているのに手数を度外視した解法はいけない。方向を加味して盤面を4倍した状態を持つということは考える前から決まっていた。BFS をしたいですね? 手探りで書いているこれは 01BFS ですか? 提出 #70805678 (AC)。1時間あっても完成しなかったからこれは終了後の提出。鏡の向きの変更を記録して考慮しないでいいのはなぜか。一度鏡の向きを変更して進路を変えたマスに紆余曲折の末再進入するケースを考える。鏡の向きを変更することで3方向どれでも好きな進路を選べるわけだけど、過去に左から入ってどこかへ出て行っていた場合、再進入して左以外のどこかへ出て行くケースは紆余曲折を省いて最初の進入時にそこへの進路を選んでいたことにすればいい。左側に出て行きたいときは? 他の経路を通って初めての進入が左側以外になったときに考えましょう(そのように取り扱えるようになっています。そしてどんな紆余曲折をたどっても U ターンして左方向へ出ていく経路はないのでこれ以外のケースは想定しません)。


2025年11月04日 (火) 楽園 Le Paradisが刊行停止を発表、2026年2月発売の次号第50号が最終号 - コミックナタリー」■悲しい。4号から買い始めて全部持ってる。雑誌で読みつつコミックスも買う作家さんも、コミックスを買うタイプではないけど雑誌では面白く読む作家さんも(すまない)、ほぼすべての連載陣がどちらかであって、奇跡的なコストパフォーマンスを誇る雑誌だった。匹敵する漫画雑誌をコミックエール!しか知らない(そちらは 12 号で終わってしまった)。刊行ペースを上げずに無理せず長く続いていると思っていたけど、50 号で終わりかあ。


2025年11月01日 (土) [AtCoder] 今日は AtCoder Beginner Contest 430 があった。■A 問題 Candy Cookie Law。人間は記号で記述された論理よりも法律やら違反やらの意味で具体化された論理の方が答えやすいらしいですよ。だからといって違反しているときに Yes と答えさせられるのはちとやっかい。前提条件をそのままに判定をひっくり返す。もしくは問題文の通りに判定して No を出力する。■B 問題 Count Subgrid。いつもやっているように指を使って数えたにもかかわらず記述を (N-M+1).times (0 から N-M までの繰り返し) から [*0..N-M+1] (0 から N-M+1 までを値とする配列) に書き換えたときに off-by-one エラーを仕込んでしまって合わないサンプルに困ってしまった。デバッグプリントで解決。■C 問題 Truck Driver。しばらくわからなくて目の前に沼が広がって見えた。今日はここまでかと。2つの条件に合う範囲をそれぞれ二分探索で求めて考え合わせる。気がつけばこれだけ。■D 問題 Neighbor Distance。お隣さんがわかれば差分更新できる。SortedSet がないから BIT で管理するんだけど X の値が大きいので座圧が必要。今でこそ座圧なんてやるだけ面倒なだけに見えて制約で手軽にいじめられてるなこのひと手間必要でしたかなんて考えてしまうけど、「座標値(-10^9 以上 10^9 以下の整数)でなく座標値の序列(N個以下とM個以下)でグリッドを作るって発想が出てこないんだよなあ」なんて初々しい感想を書いていた時期が自分にもありました。座圧ができれば橙 diff の F 問題「. (Single Dot)」が解けた時期が AtCoder にはありました。WA になった最初の提出まで 24 分かかってるんだけど、実装に取りかかる前に強制うんこ休憩に襲われて急いで E 問題を読んで駆け込んだのだった。なお E 問題のロリハ方針が決まってもまだ出られなかったもよう。WA の原因は番兵が小さすぎたこと。番兵との距離が1しかないならいないはずの番兵との距離を答えに計上して間違える。修正に2分。■E 問題 Shift String。入力が素直に2進数に見えるのでハッシュ値を比較するのもハッシュ値を差分更新するのも自然に行えると思う。マルチテストケースであり問題の見た目から基数に2が選ばれやすいだろうから、ありがちな素数の組に対してハッシュの衝突が狙いやすいと思ったけど、AtCoder で最も有名な2つの素数を使っていても大丈夫だったみたい。■F 問題 Back and Forth Filling。50 分弱残して解けなかった。似た設定でこれより答えやすい問題を見たことがある。自分の左右に最低いくつ最大いくつの数があるかを DP で求めて BIT で区間 add をすれば答えの C 数列が得られると思ったけど、サンプルが合うところまでいかなかった。■コンテスト成績証。737 位、1502 水パフォ。■■■F 問題。昨日はこう書いた。「左右に最低いくつ最大いくつの数があるかを DP で求めて……」。最大でいくつの数が置けるかを管理する必要はないのだった。最低限必ず置かなければいけない数がいくつあるかだけで良かった。前から4変数、後ろから4変数で DP をしていたものを、前から2変数、後ろから2変数に書き換えたらするっと答えが一致した。BIT もいらなかった。変化量の累積和で十分。提出 #70649443 (AC)。■■■@2025-11-11 ABC431 の結果が消えていて、ABC430 の結果は順位が同じまま 1587 パフォに上がっている。何があったんだろ。


2025年10月31日 (金) [AtCoder]「初参加者の内部レートを変更いたします - AtCoder」 ABC-rated 層では2年間で +200 程度の影響があるというのはどういうことなのか。ご新規さんを養分としてレートを吸い上げるにあたり、その養分量が 1.5 倍でうまうまとかそういう話なのだろうか。もちろん相当する実力を見積もっての変更なのだから、どちらがどちらの養分になるかは決まっていないわけだけど。


2025年10月30日 (木) [AtCoder] PAST20 の過去問の J「グリッドの禁止パターン」。どれだけの人がマス(i,j) が上から i 行目、右から j 列目のマスだと気がついただろう。そして気がつかなくても左右の区別に何の意味もないのだった。動揺させられて余分な注意を払った自分があほを見ただけ。次の K 問題「良いグリッド」もグリッドの問題だけど、これはスクリーン座標系で普通な左上が原点の設定だった。なんなん?


2025年10月29日 (水) [B! 決済] 「PayPay」命名は地獄のプロセス 候補に挙がった別案とは」■言語化について。却下するにしても理由を言語化してほしいというのはもっともな要望だけど、整えて並べられた理由よりも先に感覚的な良否の判断があるのだから、言語化が間に合わないことがあるのもしかたのない話。それに、言語化に伴って削ぎ落とされる部分というのも小さくても無意味ではなくて、結局全部をひっくるめてこそ究極の判断ができる。定石だけでは勝てないみたいなことがあるんじゃないの? そこには単純化と条件の理想化がある。PayPay はそんなにかっこいい決まり方ではなかったみたいだけど。


2025年10月25日 (土) [AtCoder] 今日は Polaris.AI プログラミングコンテスト 2025(ABC429) があった。解けるはずのものを解いただけという感じだけど 1614 の青パフォだったのは変な沼にはまらずにスムーズに AC できたから。40 分残して F 問題が解けなかったのがいつも通りのダメさ。AI が猛威をふるっていたついこの前まではこのいつもが望むべくもなかった。■A 問題 Too Many Requests。HTTP ステータスコードなのかな。番号になじみはないけど問題名は聞いたことがある気がする。400 番台がクライアント起因のエラーだということとも合致している。■B 問題 N - 1。特定の値が A 数列の中にあるかどうか。ループの外で計算してすべての仕事を Array#index に投げるのはケチだから。■C 問題 Odd One Subsequence。数列から(位置が)異なる3つの要素を選ぶ方法。Array#tally で集計して計算する。同じ数字を2つ選ぶ方法は nC2 で、残りの数字の選び方は N-n。■E 問題 Hit and Away。難しいから 425 点になっている D 問題と、E 問題だから 450 点の E 問題。解きやすいのも解いて得するのも明らかに E 問題なので D 問題を読まずに先に E 問題を開いた。最初は危険な頂点を起点にしてじわじわ広げていく陣取り的な操作を考えた。UnionFind かな、重み付き UnionFind かなと考えていって、いつもの UnionFind を書いたりもしたんだけど、詰めていくと、安全な頂点を始点にして始点により区別されるパスに先着2つまで訪問を許す BFS になった。■D 問題 On AtCoder Conference。実数 x で定義されるけど実際に求めるのは M 未満ゼロ以上のすべての整数についての合計。M が大きい。そうすると N 人の人の立っている地点と地点のあいだをすべてひっくるめて処理する必要がある。隣り合った人と人のあいだを始点とする X はどれも同じ値になるので。人と人のあいだと日本語で書くときはいいけど、実際に書く処理ではどちらかを含まない半開区間にする。どちらかっていうか、仲間はずれは区間の右端なのでそれを含まないようにする。A 数列は M を足した2周目を加えて倍加して計算しやすくする。複雑だけど 17 分でサンプルがあったから提出したら TLE×3 (#70444180)。手元でいくつかの種類の最大ケースを作ってみたけど再現できず。たぶんだけど C 人先の人が C-1 人先の人と同じ値のときはもう一人先を見る、という繰り返し処理を毎回律儀にやっていたのが良くなかった。尺取りなんだけど一端を進めたときにもう一端を(添字に C を足して) C 人先にリセットするとそれが手戻りになることがあり重複処理がかさんで TLE になっていたのだと思う。6分で修正して AC (#70446347)。■コンテスト成績証


2025年10月20日 (月) [Win11] お役立ち情報。「Unicodeフラグ、ZIPファイルの文字化け問題」■Windows 11 の送るで圧縮フォルダを作ると日本語パスが必ず化けている。Hamana で見ても LHMelt で見ても化けてるから Windows 11 の問題か Web 由来の中国系の読めない文字が混じっているせいかと思っていたけど、後方互換性を無視した Windows 11 のせいだった。たしかに Windows 11 自身に解凍させると化けないもんな。しかしこの PC ではお前が異端だ。Windows 11 がすべて悪い。■しかし、これまで化けなかったのは全部 CP932 だったからなのか。UTF-8 で保存したいのは、それはその通り。文字集合の大きさが全然違う。