2018年05月23日に初出の投稿

Last modified: 2018-05-23

総務から、メルマガに URL を掲載したいが長いので短縮 URL サービスを使いたいという相談を受けた。もちろん短縮 URL サービスはリスキーだし、利用者の心理としてもそういうサービスに慣れない方が健全だ。仮に許可しても、いちいち元の URL を調べるアドインをブラウザに入れたり、短縮 URL にマウスポインタを当てる習慣など付けるのは面倒である。ということで、短縮 URL サービスそのものはお勧めできないが、メールに書く URL が長すぎると見てくれが悪いのは確かだし、いまでは途中で勝手に line break するようなメールソフトなどあるのかどうか知らないが、60~65 文字くらいが標準的な桁数なので、勝手に折り返されると困るという事情もあろう・・・ということで、あいだを取って「自社オリジナルの短縮 URL サービス」を使ってもらうことにした。もちろん開発・実装は当部(要するに僕)の仕事ではある。

相談が済んでから、昼ご飯を取るまでに終わるだろうと考えて取り掛かってみたところ、だいたい20分くらいかかったのだが、仕組みは次のようなものだ。

・/t ... ハッシュ+拡張子のファイルを置く。

・/t/hash ... URL をハッシュ化するプログラムを置く(社内の IP でアクセス制限する)。

開発の内容は、まず /t/hash/index.html に変換用のページを置く。フォームで URL を入力してもらい、/t/hash/trans.php で POST のデータを受けて、ハッシュ化した文字列と URL の対応を作り、/t の直下に /t/{hashed}.php というファイルを生成して、このファイルの中に飛ばしたい URL と header(); 関数を書けばよい。/t/hash ディレクトリさえ保護しておけば、/t/{hashed}.php への大量アクセスさえ防げば、他にリスクはない(そもそもファイルに対する大量アクセスというリスクは、他のページに対しても最初からある)。

ハッシュ化する際のアルゴリズムは、桁数とか、自社で使うので大量の変換はしないから衝突可能性はさほど高くないと考えて、8桁で済む CRC32 としてある。実際、他のサービスでも8桁のところは CRC32 とかを使っているのだろう(まさか「sha256 の先頭の8桁」とかアホなことはしていまい)。・・・というか、そんなレベルの話題など大したことはない。実装してみてから気付いたのは、FQDN が長くて短縮している気がしないということだ(笑)。

もちろん、本当に衝突可能性を気にするのであれば、/t/{hashed}.php を出力するハッシュを生成するときに file_exists() で判定してから処理を進めればいい。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook