2015年7月、Physical Webプロジェクトの成果を取り込む形で、Eddystoneという規格がGoogleより発表された。ビーコンの振る舞いに関する規格で、その主なところは発信するパケットのフォーマット（フレームと呼ぶ）の定義だ。今回は、このEddystoneについて詳しく解説する。
Eddystoneでは、以下の4種類がフレームとして定義されている。（1）～（3）は2015年7月の規格発表当初に定義されたフレーム。（4）は2016年4月に追加された新しいフレームだ。
（1）Eddystone-URL
（2）Eddystone-UID
（3）Eddystone-TLM
（4）Eddystone-EID
Eddystoneのフレームは全て、BLEのアドバタイジングパケットのServiceDataというフィールドに格納されて運ばれる。以降、各フレームについて順に見ていこう。
Eddystone-URL
Eddystone-URLは、前回説明したUriBeaconの名前が変わっただけだと思ってよいだろう。パケットフォーマットなどの仕様もほとんどそのままだ。
BLEの説明で触れた通り、アドバタイズのパケットに詰めこめるデータは非常に小さなものとなる。そのため、どんな長さのURLでも詰めこめるというわけではない。
まず、以下の変換ルールに従い、スキーム部分を圧縮する。
例えば先頭が「https://www.」で始まる場合は、そこを0x01という1バイトで表現する。
また、TLD（トップレベルドメイン）にも変換ルールがあり、それに従い圧縮を行う。例えば、「.com/」は0x00に、「.net/」は0x03に、といった具合に置き換える。他の例は［このサイト］を参照されたい。
Eddystone-URLで、URLのために使えるバイト数は18バイトである。このような圧縮を使って18バイトに収まるURLなら、そのまま設定するとよいだろう。それで収まらなければ、goo.glのような短縮URLサービスを使う必要がある。
例えば次のようなURLをビーコンから発信する場合を考えてみよう。https://too-long-domain.example.org/too-long-path/
「https://」や「.org/」を、それぞれ1バイトずつに圧縮したとしても18バイトを軽く超えてしまう。
goo.glで短縮URLを作ると次のようになる。https://goo.gl/CsMC8H
「https://」の箇所を0x03という1バイトの文字列に置き換えると、14バイトに収まる。
タイトルやサムネイルなどのメタデータを取得する際、Physical Web ServiceというWeb APIを介すると前回説明した。実はこのとき、必要であれば短縮URLの展開などもしているわけだ。
Eddystone-URLのパケットフォーマットは次のように定義されている。
Eddystone-URLフレームはこれまでに説明した通り、Physical Webというエコシステムを実現するために利用される。
提供したいデータがパブリックにしても問題ないものならば、このフレームの採用を検討するといいだろう。URLのドメインなどをフィルタリングすることで専用アプリでも利用できるし、既存のChromeや、あるいは他に標準ブラウザーのようなものが登場した際にも、その上で表示させることができるだろう。
