形式ではなく、状況でまとめる
このカテゴリーはテーマというより引き出しのようなものです。ここにあるツールは、それ自体が本来の作業ではなく、別の作業をしている最中に必要になる小さな変換ばかりなので、ここでは手を伸ばすときの状況ごとに並べています。
「このログに得体の知れない文字列があって、何なのか分からない。」 550e8400-e29b-41d4-a716-446655440000のような形なら、UUIDデコーダーがバージョンを教えてくれ、v1、v6、v7であれば生成時のタイムスタンプも表示します。SGVsbG8=のような形や==で終わっているならBase64なので、デコードしてください。17で始まる裸の10桁の数字なら、それはだいたい今の時刻を示すUnixタイムスタンプです。
「IDが必要だ。」 UUIDジェネレーターはv1と、v3からv7までを生成でき、テスト用データベースの初期データ作成のために一度に数千件を生成することもできます。
「このタイムスタンプが1,000倍ずれている。」 秒かミリ秒か——タイムスタンプコンバーターはどちらも扱え、あなたが与えたのがどちらだったかも表示します。
「このデータURIを実際のファイルにしたい。」 あるいはその逆に、Base64から画像へ。
「これは正確には何色なのか？」 表記の間を変換するならカラーピッカー、スクリーンショットやモックアップから値を読み取るなら画像カラーピッカー。
「これはsnake_caseにしないといけないのに、camelCaseになっている。」 ケースコンバーター。
「0xDEADBEEFは10進数でいくつで、符号付きだった場合はどうなるのか？」 ほとんどのツールと違い、負の数と2の補数を扱える進数コンバーター。
識別子は思っている以上に情報を漏らす
どのツールのページにも属さない、横断的に言っておく価値のあることが1つあります。これらの形式のいくつかは、あなたが公開するつもりのなかった情報を運んでいます。
UUID v1にはタイムスタンプとマシンのMACアドレスが埋め込まれています。 これは元々の設計思想で、「このマシンで、この瞬間に」という条件で一意性を保証するものでした。つまり、公開URLに含まれるv1のUUIDは、そのレコードが正確にいつ作られたかを知りたい人に教えてしまい、それを作ったサーバーの安定した識別子まで与えてしまうということです。これはデコーダーに1つ貼り付けてみれば自分で確認できます。
UUID v7にもUnixタイムスタンプが埋め込まれています。 これは意図的なもので、IDでソートすることと作成日時でソートすることが同じ結果になるのは、データベースのインデックスの局所性にとって非常に有用だからです。その代償は同じ情報漏洩です。v7のIDは順序付けられているため、公開すると作成日時が明らかになり、2つを観察するだけで1時間あたりどれくらいレコードを作っているか推測できてしまいます。
何も明かさないのはv4です。 122ビットのランダム性だけで構造を持ちません。だからこそv4は、ユーザーに見える用途では今もデフォルトであり続けており、同じテーブルで「主キーにはv7、公開用の識別子にはv4」というのが理にかなったルールになるのです。
Base64はすべてを瞬時に、誰に対しても明かします。 これは難読化ではありません。Kubernetesのシークレットは、バイナリの値がYAMLの中で壊れずに残るようにBase64でエンコードされているのであって、保護するためではありません。
このページ上のすべての処理はローカルで完結し、このカテゴリーではそれが他のどのカテゴリーよりも重要です。本番環境の識別子やトークン、ログの断片は、まさに他人のサーバーに貼り付けてデコードしてもらうべきではない種類のものだからです。