作業の合間に必要になる変換と検査の道具です。すべて手元で動くので、社内のデータを他社のサーバーに貼り付けずに済みます。
JSON の整形や JWT の中身確認を検索すると、道具は何十も出てきます。問題は、その多くが入力をサーバーへ送って処理することです。その JSON に顧客のメールアドレスが入っていて、その JWT が有効なセッショントークンなら、貼り付けた瞬間に外部へ出たことになります。
「どうせ期限切れのトークンだから」と流しがちですが、事故調査で問題になるのは漏れたかどうかより、どこまで出たかを証明できないという事実です。
この分類の道具はすべてブラウザ内で動きます。確認は十秒で済みます。開発者ツールのネットワークタブを開いて使ってみてください。要求は発生しません。
JSON 整形は見た目を整えるためより、構文エラーの位置を知るために使われることのほうが多い。よくある原因は末尾の余分なカンマ、単引用符、複製の過程で混入した不可視文字です。
Base64 は暗号ではありません。誰でも戻せる符号化であり、秘密を隠す用途ではなく、バイナリをテキスト経路に載せる用途です。URL に入れる場合は + と / が問題になるため、- と _ を使う URL-safe 版が必要です。
URL エンコードでは、どの部分を符号化するのかが常に要点です。パスの区切りと問い合わせ文字列では逃がすべき文字が異なり、URL 全体をまとめて符号化すると :// まで壊れます。
JWT は点で区切られた三つの部分(ヘッダー・ペイロード・署名)で、前の二つは単なる Base64URL です。つまり誰でも読めます。トークンに個人情報や内部識別子を入れるのは、公開するのと同じことです。
復号器が行うのはその二つを読むことだけです。署名の検証は別の操作であり、それを経なければ内容の真正性は何も保証されません。alg: none を受け入れる実装が実際の脆弱性となったのはこの隙間です。
有効期限(exp)と発行時刻(iat)は Unix 時刻なので人の目には意味がありません。時刻変換器と併用すれば、そのトークンがいつ失効するかがすぐ分かります。
正規表現が最も外れるのは貪欲な量指定子です。.* は可能な限り長く取るため、<.*> は一つのタグではなく最初の < から最後の > までを掴みます。.*? で怠惰にするのが最初の処方です。
cron の定番の罠は日と曜日を同時に指定することです。多くの実装でこの二つは AND ではなく OR として働くため、意図よりはるかに頻繁に実行されます。またサーバーの時間帯を確認しなければ、「午前三時」が別の時間帯の午前三時かもしれません。
CIDR の計算では、使えるホスト数は 2^(32−prefix) ではなく、そこからネットワークアドレスとブロードキャストアドレスの二つを引いた値です。/30 が四つではなく二つになる理由であり、/31 は点対点リンク用の特例です。
時刻変換では、秒と ミリ秒の取り違えが事故のほとんどです。十桁なら秒、十三桁ならミリ秒。千倍の差なので、1970 年や五万年後が出たらこれを疑ってください。
差分比較は行単位で見るか文字単位で見るかで結果がまったく変わります。コードレビューには行単位、文中の誤字探しには文字単位が向きます。
色変換は HEX・RGB・HSL を行き来しますが、「少し明るく」のような調整には HSL がはるかに扱いやすい。一つの成分だけを動かせば済むからです。
QR 生成では誤り訂正の水準を選べます。水準を上げると符号は密になりますが、印刷が汚れたり一部が隠れても読み取れます。
サーバー容量の見積もりは待ち行列理論の基本式であるリトルの法則に立っています。系の中にある要求数は「到着率 × 滞在時間」であり、そこから必要な同時処理数が出ます。
直感と異なるのは、利用率が 100% に近づくほど待ち時間が急激に膨張する点です。70% から 80% へ上げるときより、90% から 95% へ上げるときのほうが応答時間の悪化がはるかに大きい。「CPU にまだ 10% の余裕がある」は安全の合図ではありません。
これは定常状態の近似であり、瞬間的な急増や再試行の嵐は模型に入っていません。容量計画の出発点として使い、実際の負荷試験で確かめてください。
すべてブラウザ内で動き、オフラインでも使え、入力したコードやトークン、設定値をサーバーへ送りません。会員登録がないため、どの値も個人と結び付きません。
一方でブラウザという制約もあります。非常に大きな入力はメモリを多く使い、実際の通信が必要な検査(ポート走査、TLS 証明書チェーンの検証など)は行えません。