開発でよく使う変換器・検査器・ファイル道具をまとめました。すべてローカル処理で、コードやデータを外に出しません。
このコレクションの道具はファイルも文字列もサーバーに送りません。 JSON の整形も Base64 のデコードも JWT の中身確認も、画像圧縮も PDF 結合もタブの中で終わります。
これが好みの問題でないのは、開発中に扱う文字列の中身が理由です。デコードしたい JWT には実際のユーザー識別子と署名が入っていますし、整形したい JSON レスポンスは本番データです。オンラインの整形サイトに貼った時点で、それは他社サーバーに残るログになります。
社内規程が外部ツールを禁じている場合、禁じている対象は道具ではなくデータの送信です。送信がなければその条件は自動的に満たされます。ネットワークタブを開いたまま使えば、リクエストが出ないことをその場で確認できます。
まずログに出た正体不明の文字列をほどきます。eyJ で始まれば JWT、末尾が = なら Base64 です。JWT は暗号化ではなく署名なので、ペイロードはそのまま読めます。最初に見るのは有効期限(exp)と発行時刻(iat)がサーバーの時計と合っているかです。
次がタイムスタンプです。1970 付近の日付が出たら、秒をミリ秒として読んだか、その逆です。ログの時刻が UTC かローカルか分からないときも、一度変換すれば決着します。
設定のずれを探すときは差分を使います。デプロイ前後の設定を並べると、「何も変えていない」が事実でなかったことがたいていここで分かります。
cron 式で間違えやすいのは曜日と「N 分ごと」です。*/5 と 5 はまったく別のスケジュールで、その一文字がバッチを 1 日 288 回動かすか 1 回にするかを分けます。
「このサーバーで何人さばけるか」はスペック表からは出ません。必要なのはリトルの法則です。同時処理数 = 到着率 × 平均応答時間。サーバー負荷シミュレーターが計算しているのはこれです。
見落とされやすいのはボトルネックの位置です。CPU コアを倍にしても、コネクションプールが 20 なら最大スループットはそこで切られます。いちばん狭い区間が全体の処理量を決めます。
応答時間の伸び方も線形ではありません。使用率が 70% を超えると待ち時間が急に立ち上がります。平常時の使用率に余裕を持たせるのは無駄ではなく、遅延の安定を買う費用です。
この計算は正確な予測ではなく桁の確認です。必要なのが 2 台か 20 台かを会議前に知るためのものです。実際の数値は負荷試験で測ります。
スクリーンショットが 8MB でイシューに添付できない、PDF 3 枚を 1 つにまとめて提出する必要がある。開発者にもよくある場面です。そのたびに ImageMagick を入れる必要も、変換サイトにファイルを上げる必要もありません。
圧縮は二つの軸で見ます。解像度(リサイズ)と品質(再エンコード)です。4000px の画像は品質だけ下げるより 1600px に縮めるほうが、見た目の劣化に対する容量削減がずっと大きくなります。資料用のスクリーンショットなら長辺 1600px で足ります。
PDF の結合も画像から PDF への変換も同じ場所で終わります。契約書や領収書のような上げてはいけない書類がこの二つの主な入力なので、アップロードがないという性質がここで最も効きます。
送信がなくても画面は残ります。画面共有中に本番トークンをデコードすれば、それ自体が漏洩です。
デコード結果をそのままチケットやチャットに貼るのもよくある事故です。JWT のペイロードにはユーザー ID・メールアドレス・権限がそのまま入っていることが少なくありません。
正規表現を試すときは本番データではなく形だけ同じサンプルを使ってください。パターン合わせに必要なのは形であって実際の値ではありません。
ここにあるのは確認用の道具です。JWT のデコードは署名検証ではありません。検証は鍵を持つサーバーが行うものです。ペイロードが読めることと、そのトークンが有効であることは別の話です。
負荷シミュレーターは実際の負荷試験の代わりにはなりません。GC の挙動、カーネル設定、ネットワーク遅延、キャッシュヒット率が実測値を動かします。
非可逆圧縮は元に戻せません。原本は別に残し、圧縮版だけを配布してください。