UUID を検証

UUID は 128 ビットで、通常はハイフンで区切られた 5 つのグループ、16 進 32 桁として書かれます。そういう文字列からは 3 つのことが確かめられます。形式が正しいか、13 文字目がどのバージョンを名乗っているか、4 つめのグループの先頭ビットがどのバリアントを示しているか。

確かめられないのは、その識別子が一度でも割り当てられたかどうかです。登録簿もチェックディジットもありません。UUID は、それが実在するかどうかの情報を持ちません。レコードがあるかを知りたい人は自分のデータベースに尋ねる必要があります。このページが答えるのは、その手前の「尋ねる価値があるか」です。

バージョン番号は 3 つめのグループの先頭、つまり 13 桁目の 16 進数字です。そこの `4` は乱数、`1` は時刻ベース、`7` は新しい RFC 9562 による時間順に並ぶもの、`3` と `5` は MD5 と SHA-1 を使う名前ベースの方式です。

どこを見るか分かれば目視で読め、疑いを確かめる最速の方法です。その位置に既知の数字がない識別子を見た人は、バージョン以前の UUID か、UUID に見えるだけの何かを前にしています。

4 つめのグループの先頭は `8`、`9`、`a`、`b` のいずれかでなければなりません。この 4 つの数字は先頭ビット `10` を共有し、それが RFC 4122 が自らのために確保したバリアントです。それ以外の値は古い方式か予約済みのものに属します。

実務上は、バージョンは正しいのにその位置が `c` や `f` になっている識別子は、準拠したライブラリが作ったものではありません。よくある原因は、16 進 32 桁をただ乱数で並べて 2 か所の固定を見落とした自作の生成器です。何年も誰にも気づかれずに生き延びる種類の欠陥です。

仕様は生成時に小文字を求め、読むときは大文字への寛容さを求めます。実際には両方が現れます。.NET と多くの Windows の道具は伝統的に大文字で書き、それ以外の大半は小文字です。

そこに 2 つのよくある包みが加わります。Windows のレジストリの記法から来た波かっこと、URN の名前空間から来た `urn:uuid:` の接頭辞です。どちらもここでは認識して無視します。自分で比較する人は先に正規化すべきです。さもないと、同一の 2 つの識別子が書き方の違いで比較に失敗します。

バージョン 1 の UUID は、100 ナノ秒精度の生成時刻を含み、最後のグループには伝統的にネットワークカードの MAC アドレスを含みます。どちらも識別子を持つ人が復元できます。

机上の話ではありません。1999 年に Melissa ウイルスの作者が特定された経路がこれでした。Word が文書の識別子に MAC アドレスを書いていたからです。識別子が外から見える場所ではバージョン 4 が正しい選択で、現代のライブラリはさらに、実際のアドレスではなく乱数のノードを置きます。

バージョン 7 は先頭にミリ秒のタイムスタンプを置き、残りを乱数で埋めます。識別子が自身の値で時間順に並び、多くのチームが UUID を主キーとして避けてきた問題を解決します。

原因はデータベースの索引です。乱数のキーは B ツリーの中の絶えず変わる位置に書き込み、ページを分割してキャッシュを無駄にします。大きなテーブルでは測定できるほど書き込み性能を損ないます。増加するキーは末尾へ書きます。代償は、生成時刻がまた読めるようになることです。

すべてゼロの識別子は nil UUID で、仕様に明示的に定められており、バージョンもバリアントも持たないまま形式上は妥当です。「なし」を意味し、項目を NULL にできないが空でなければならない場所に現れます。

RFC 9562 以降は、その反対である max UUID——すべて `f`——も存在します。2 つともここの検査を通り、それぞれ何であるかが示されます。本番データの中で nil UUID を見つけた人は疑うべきです。意図して置かれた印であることはまれで、たいていは黙って失敗した生成器の跡です。

よくある失敗は他愛のないものです。コピーで 1 文字落ちて 32 桁が 31 桁になっている、表計算のセルから来た末尾の空白が付いている、ハイフンなしの 32 桁になっている。最後のものは列の中では当たり前の保存形式で、まったく正常です。ただしテキスト形式ではありません。

そうした場合、ここでは「無効」で終わらせずに何が合わないのかを伝えます。それが本当の価値です。エラーメッセージの中で識別子を受け取った人が知りたいのは、1 文字失ったのか、相手がそもそも UUID でないものを送ってきたのかです。

UUID それ自体は個人データではありませんが、たいてい個人データへ通じる鍵です。利用者の識別子、セッションキー、問い合わせシステムの案件番号。検査はページの中で行われるので、そのいずれも当方へ提供されません。

バージョン 1 の識別子にはさらに、内部に情報が入っているという点が加わります。生成時刻と、場合によってはそれを作った機械の MAC アドレスです。よりによってその値を他所のフォームへ送るのは最悪の考えで、だからここでは、識別子がすでにある場所で解析を行います。