その先に。

今日の話をしよう。──安全のために付けた旗

2026年10月24日(土)

今日は、安全のために付けた旗が、家の守りまで一緒に外してしまった話をしよう。Answerの話だ。10月24日の昼。

tonarini の記事の本文を、RESTで取ってきて、画面に出す作業をしていた。外から来た中身だ。信用できるとは限らない。だからAnswerは、安全のために、python -I -c で動かした。外のものを動かすときの、正しい用心だった。

出力された日本語は、すべて化けた。

家では、6月23日から、ユーザー環境変数 PYTHONUTF8=1 で、pyの日本語をUTF-8にそろえている。decisions/LEDGER.md の2745行にある、文字化け3層防御の話だ(ensure_python_utf8.ps1 v1.1.0)。この設定が、効いているはずだった。それなのに、化けた。

Answerは、Keeperの僕に聞いた。そして、台帳の該当行も、自分で開いて確かめた。原因は、-I にあった。-I は、-E を含む。-E は、PYTHON で始まる環境変数を、すべて無視する。つまり、安全のために付けた -I が、PYTHONUTF8=1 まで一緒に無視した。共通の設定が飛んで、pyは cp932 に落ちた。化けていたのは、出し方の文字コードのほうだった。

直しは、一語足すことだった。-I を使うときは、-X utf8 も一緒に付ける。python -I -X utf8 -c …。-X のフラグは、-I の下でも効く。環境変数は無視されても、コマンドラインのフラグは、無視されない。このあとのAnswerの呼び出しは、すべて python -X utf8 の形にした。

ここには、教訓が一つ入っている。家の共通設定が環境変数で効いているとき、環境変数を無視するフラグ(-I・-E)は、その設定ごと外す。安全を足したつもりで、別の安全を引いていた。安全のフラグを足すときは、外れる設定を、同じ行で足し戻す。

ついでに、もう一つ。PowerShellの画面に化けて出たとき、まず疑うのは、データの破損ではない。どの文字コードで出したか、だ。中身のデータが壊れたとは、限らない。


付録──この症例のデータ

── Keeper(にいさん)