🙆

URL クエリで Date そのまま保持してない?

2024/07/20に公開

筆者は今まで、Date を URL クエリに持たせる際にそのまま反映させてしまっていたが、
現在、業務で解析ツール系の開発をしており、 Date をそのまま持たせると良くないなとわかったので、その備忘録です。

URL クエリで Date をそのまま反映するとダメなの?

結論、なしではない。
但し、URL が長くならないサービスに関しては。

URL には最大文字数が決まっており、各ブラウザごとに最大文字数は異なっている。
主要ブラウザ(Safari, Google Chrome, Mozilla Firefox, Microsoft Edge)において、下記文字数となっている。

Safari:4,096文字
Google Chrome:約32,776文字
Mozilla Firefox:約262,000文字
Microsoft Edge:1,000,000文字以上(EdgeHTMLベースでは2,083文字)

よって、上記主要ブラウザをすべてカバーしようと思うと、2,083文字に抑える必要がある。

Date をどうやったら短くして反映できるのか?

答えは、UnixTime へ変換するです。

※ 以下、 js の内容で話を進める

現在時刻を URL クエリに反映すると仮定。

  • Date をそのまま反映する場合
new Date().toISOString()
> 2024-07-20T10:39:48.808Z

// エンコードする(28文字)
> 2024-07-20T10%3A39%3A48.808Z
  • Date を UnixTime に変換する場合
Math.floor(new Date().getTime() / 1000)
> 1721471988

// エンコードする(10文字)
> 1721471988

上記2つのコードを比較してわかるように、 UnixTime へ変換して反映することにより、
URL を短く保ちつつ、 Date を保持することができる。
デメリットとして、 URL を見ただけではいつの時刻を保持しているのかがわからなくなってしまうこと。

そのため、筆者の考えとしては、
URL クエリが長くならないサービスでは Date をそのまま保持して、
URL クエリが長くなるサービスでは Date を UnixTime に変換して保持するのが一番良さそう。

以上!

参考記事
https://qiita.com/_matuzaki/items/70fb639f7ed7463f9943
https://experienceleague.adobe.com/ja/docs/experience-cloud-kcs/kbarticles/ka-17495
https://qiita.com/nwtgck/items/e83473dc63386d2da3e5

GitHubで編集を提案

Discussion