JSON整形・Base64・URLエンコード・正規表現テスト・UNIXタイムスタンプ・JWTデコード・Cron式・テキスト差分をひとつのページにまとめました。すべてブラウザ内で処理するので、貼り付けた内容は外部に送信されません。
インデントが揃うのは副次的な効果にすぎません。実務で効いてくるのはどこで構文が壊れたのかを教えてくれることです。APIが「不正なJSONです」としか返さないとき、何文字目で崩れたかが分かれば原因はたいてい一目で見えます。
崩れる原因の大半は三つに絞られます。最後の要素のうしろに残った末尾カンマ、シングルクォート(JSONが認めるのはダブルクォートだけです)、そしてコメント(JSONにコメント構文は存在しません)。設定ファイルの感覚で書くとこの三つを踏みます。
キーをアルファベット順に並べ替えると、二つのレスポンスを差分比較できるようになります。中身がまったく同じでもキーの並び順が違えば、差分ツールは全行が変わったと報告してしまうからです。
Base64はバイナリをテキストとして表現するための符号化です。メールやJSONのように文字しか通せない経路にバイトの並びを載せるために作られました。
鍵という概念がありません。誰でも一瞬で元に戻せます。Base64で「隠した」パスワードは平文のパスワードと同じだと考えてください。
データ量はおよそ33%増えます。3バイトが4文字になるためで、画像やファイルを埋め込むときは無視できない差になります。
URLに載せるときは + と / が問題を起こすので、base64urlという変種が - と _ に置き換えます。JWTが採用しているのはこの方式です。
encodeURIComponent は &・=・?・/ まで含めて変換します。クエリパラメータの値に使う関数です。
encodeURI はそれらの記号をそのまま残します。URL全体をエンコードするための関数です。
値のほうに encodeURI を使うと、値の中の & がパラメータの区切りと解釈されてデータが途中で切れます。逆にURL全体に encodeURIComponent をかけると :// まで変換されてリンクが壊れます。
空白が %20 になったり + になったりするのは文脈の違いです。前者はURLのパス、後者はフォーム送信(application/x-www-form-urlencoded)の慣習です。
JWTはドットで区切られた三つの部分でできています。ヘッダー(アルゴリズム)・ペイロード(クレーム)・署名の三つです。
前の二つは単なるbase64urlです。暗号化されていないので誰でも読めます。JWTのペイロードに秘密情報を入れてはいけないのはこのためです。
署名の検証には秘密鍵または公開鍵が必要になります。このツールが表示だけにとどめているのは意図的です。署名鍵をWebページに貼り付けさせること自体がセキュリティ上の問題になるからです。
ペイロードの exp(有効期限)・iat(発行時刻)・nbf(有効開始)はUNIX秒です。人間が読める時刻に直すと、「トークンが期限切れです」というエラーの理由はたいていその場で分かります。
五つの欄はそれぞれ分・時・日・月・曜日です。0 3 * * * は毎日03:00に実行されます。
古典的な罠が一つあります。日と曜日を両方指定するとANDではなくORになることです。0 0 1 * 1 は「毎月1日、および毎週月曜日」であって「1日かつ月曜日」ではありません。
*/15 は15分ごとですが、0分を起点にした0・15・30・45分であって、任意の時点から15分間隔という意味ではありません。
曜日は0と7の両方を日曜として受け付ける実装が多くあります。使っている環境の仕様を確認してください。
タイムゾーンを必ず確認してください。サーバーがUTCで動いているなら 0 9 * * * は日本時間の18:00です。手元の感覚で書くとまる9時間ずれます。
192.168.1.0/24 の /24 は先頭24ビットがネットワーク部という意味です。残る8ビットがホスト部なので256個のアドレスが取れます。
実際に機器へ割り当てられるのは254個です。最初のアドレスはネットワークアドレス、最後はブロードキャストとして予約されます。
数字が小さいほど範囲は広くなります。/16 は65,536個、/24 は256個、/32 は1個(単一ホスト)です。この向きを逆に覚えているのが最も多い間違いです。
ファイアウォールやセキュリティグループの規則では 0.0.0.0/0 がインターネット上のすべてのアドレスを指します。SSHポートをこれに開けたままにするところから事故が始まります。
すべての変換はブラウザの中で完結します。リクエストは一切発生しません。
これは実務では小さくない違いです。デコードしたいJWTには生きた認証トークンが入っていますし、整形したいJSONには顧客データが入っています。それをオンラインのツールに貼り付ける行為は、そのまま情報流出の経路になります。
このページはその経路を作りません。ブラウザのネットワークタブを開いたまま操作して確かめてもらってかまいません。
正規表現は書くより試すほうが速い種類の道具です。手元のサンプル文字列に対してその場で一致箇所を確かめられると、括弧の対応や量指定子の貪欲さといった間違いがすぐ表面化します。
UNIXタイムスタンプは1970年1月1日からの経過秒数です。秒とミリ秒の取り違えが最も多い事故で、10桁なら秒、13桁ならミリ秒と覚えておくと桁数だけで見分けがつきます。
テキスト差分は設定ファイルやAPIレスポンスの比較に効きます。ただし行末の改行コードや末尾の空白が違うだけでも差分として現れるので、意味のある違いが見つからないときはその可能性を疑ってください。
JSON整形、Base64とURLのエンコード、正規表現テスト、タイムスタンプ変換、JWTデコード、Cron式、CIDR計算、テキスト差分です。
いいえ。すべてブラウザ内で処理するので、社内のデータを外部サーバーに送らずに使えます。
いいえ。ペイロードとヘッダーの中身をデコードして表示するだけで、署名の検証は行いません。