短縮URLサービスはなぜ「http://……」というURLがスタンダードにならなかったのでしょうか？

短縮URLサービスでURLを短縮すると「https://……」という風に取得できるWebサービスが多いようですが、

「短縮URL」というぐらいなら「http://」または「http:」表記で出力されるのが理に適ってると思うのですが、なぜ「https://」が選ばれるようになったのでしょうか？

質問者からの補足コメント

• 申し訳ございませんが、質問を変えます。
  
  • 例えば「https:tansyuku.ly/Id」のように、もし昔から短縮URLサービスが「https://……」ではなく「https:……」で出力する事が多かった場合、今ではURL「https:……」表記がデファクトスタンダードになっていた可能性はありますか？
  
  • 短縮URLは(//を省いた「http:……」のように)もっと短くできるのに、なぜ どこの短縮URLサービスも「https://……」表記で取得されるようにしていて、URLを短くしなかったのでしょうか？

    補足日時：2025/03/17 20:28

• • 短縮URLは(//を省いた「https:……」のように)もっと短くできるのに、なぜ どこの短縮URLサービスも「https://……」表記で取得されるようにしており、もっとURLを短くしなかったのでしょうか？〔※誤字訂正済〕
  
  回答へのお礼にも微妙に誤字脱字があり、申し訳ございません。

    補足日時：2025/03/17 20:39

• 皆さん回答ありがとうございます。
  
  URLの仕様を当時決めた人が「http://」について、「スラッシュは2個もいらなかったかも。」という話をどこかで聞きかじった覚えがあるのですが。
  
  • 例えば、もし昔からTwitterとか有名な所が リンクを貼った投稿内容の表示が、「投稿テスト: <a href="https://t.co/RIpbP7n5kH">https:example.com<a>」のような表示だったら、今頃のURLは //が省略されているのが標準であったり 仕様がそう変わっていた可能性はありますか？
  
  空想的になってしまうとは思いますが、もし似たような事例があれば用い出して頂くとさらに幸いです。

    補足日時：2025/03/18 18:55

No.14 回答者： k-841 回答日時： 2025/03/24 12:49

No.10です。

察するに、あなたはより良い使い方ができそうな方法を思いついたからそれを提案したいということなのですね。であれば、インターネットの標準化を取りまとめているIETFに提案するのが近道ですし、恐らくそれが唯一の方法です。世界共通の規約はRFC（Request For Comments）で定められています。

URIはRFC3986にで規定されています。
https://datatracker.ietf.org/doc/html/rfc3986

特にHTTPに関する規定はRFC7230に記載されています。
https://datatracker.ietf.org/doc/html/rfc7230

これらを更新する内容を提案してみるといいかもしれません。もちろんすべてが通るとは限りませんし、個人的な感想としては恐らく拒否されると思います。

なお「デファクトスタンダード」というワードが出てきていますが、デファクトスタンダードは新技術以外では通用しません。ずっと昔MicrosoftはいくつかRFC違反のソフトウェアをばらまいてきたことがありましたが、これらは基本的に改善されています。

No.13 回答者： kmee 回答日時： 2025/03/22 15:14

「URLの短縮」と言っていますが、そう見えるだけで、URLを短かくする仕組みではありません。

本質は「コードを指定したら、対応する登録されているURLへリダイレクト(転送)するサイト」であり、短いホスト名 + 短いコード を使っているので、結果的に元のURLより短かくなる(ことが多い)、というだけです。

使うURLは従来と同じ仕様です。
「URLの仕様を変えてでも、1文字でも短く」といった考えはありません。

No.12 回答者： artoo 回答日時： 2025/03/22 03:47

No5です。

> 『相対URLをhrefに指定する場合は～～「./」を省略しない事を推奨。
> UNCも『相対URLの場合は「.\」を省略しない』

既存の相対URLを書き換えないといけなくなる変更はあり得ないです。
それは、先に書いた通り、

> ただ、過去との互換性があまり沢山なくなったり、～～ような変更は無理でしょうね。

ということです。

> 『絶対URLのスキームは「http:example.com」のように、ホスト名の前にコロンが付いていたらスキームと解釈する』　という仕様が浮かびました。

スキームのあとの example.com がホスト名であるのか、パスの一部（ディレクトリ名かファイル名）のどちらであるかを解釈するのかの2案があり得るが、後者が自然であろうと書いたとおりです。
「スラッシュで始まらないのは相対パス」というずっと続いている習慣を尊重するのであればですが。

> つまり、～～～ ツールにも影響が出るほど大きく変わると思ったのですが。

URLの仕様が過去と非互換な仕様に変更されれば、既存のHTMLやプログラムは全部書き直しで、開発ツールも全部書き直しなので、そういうことです。
なので、そういうことが必要になる変更がされることはないでしょう。

> もう今更URLの仕様について、ダブルスラッシュの部分から変える事は、慣習的な理由もあってほぼ不可能であるように理解しました。

はい。その通りです。「慣習的」というか「現実的な理由」ですかね。

「これからURLのルールを初めて決める。過去の資産は全くなし」
ということであれば、検討対象になりえると思いますが、2文字の省略を可能とするためだけに、全体的な整合性がとれないルールが採用されることは無いでしょうね。
「全体的な整合性がとれない」は私見なので、頭のいい人が整合性がとれる形で考えてくれるかも知れませんが、いずれにせよ40年前か50年前かに戻ってやり直す話なので、そこをあまり真剣に考えてもしょうがない。

2文字省略したいなら、http: https: と同じ意味で例えば hp: hps: と2文字短いスキームを（変更じゃなくて）新設する修正であれば、過去の資産はそのままなので、ブラウザ自体などの修正だけで可能ですが、「誰得？」な感じなので、これをルールに追加するのは困難でしょうね。40年前に戻るよりはましですが。

繰り返しになりますが、ブラウザのアドレスバーに手入力(orコピペ)するなら、「// を省略した https:bit.ly/※※」だけじゃなくて「https:// を省略した bit.ly/※※」でも効くと思うので、自分の責任でそのように省略しても良いかと思います。8文字短くなります。

No.11 回答者： artoo 回答日時： 2025/03/21 01:27

No5ですが、お礼中の質問に対しての回答です。

> 一旦URLの仕様を当時決めたら、後にダブルスラッシュが省略される仕様が「許容可能」 というような仕様にはできないのでしょうか？

仕様の変更は議論して合意が取れれば可能です。
ただ、過去との互換性があまり沢山なくなったり、また、直感的な理解と異なるような変更は無理でしょうね。

URLには、「スキーム」や「スキームとホスト名」や「スキームとホスト名とパス」を省略した相対URLという物があります。
たとえは、https://example.com/aaa/bbb.html というHTMLページの中に
<a href="ccc.com/ddd.html">というリンクがあれば、
https://example.com/aaa/ccc.com/ddd.html を意味するというのはご存じかと思います。ccc.com/ddd.html は「スキームhttps:とホスト名example.comとパスの先頭/aaa」を省略した相対URLです。

<a href="http:ccc.com/ddd.html"> と書くのは今は不正なURLです。
これを正しいURLであると認める際に、
案1: http://ccc.com/ddd.html （ホスト名の前の // は省略可能とする変更）
案2: http://example.com/aaa/ccc.com/ddd.html （相対URLにスキームの指定だけ許すという変更）
のどちらと解釈するのが自然か？私の直感では案2ですね。まあ、どっちも賛成はしませんが。

あとこれは多分Microsoftが考えた仕様だと思いますが（裏は取ってないのでMSが考えたというのは推測）と思いますが、
\\server-name\share-name\folder1\folder2
のようなネットワーク上のフォルダーやファイルの名前を表す UNC（Universal Naming Convention）という記法があります。URLの//の省略を許すと、これの \\ との整合性も崩れますね。UNCの \\ の省略は無理です。
（ aaa\bbb\ccc は相対パスとして意味があるので、\\aaa\bbb\ccc と思えというのは無理 ）
まあ、この整合性が崩れたら駄目かという議論も難しいですが。

案1、案2や、UNCどうするとか言った議論をしてまでURLの定義を変更するメリットがあるのかどうか？議論しても、案2になるかもしれない。

先のNo5の回答で書いたように、
> これも誰が決めるの？という話で、あなたが、一般の短縮URLサービスを使って、自サイトの短縮URLをhttps://bit.ly/※※ と取得したあとで、「自サイトの利用者はメジャーなブラウザから使う人が100%である」と判断して https:bit.ly/※※ と周知するのは状況によっては問題ないかもしれません。

だと思うので、現状で、あなたが自分の責任で判断して省略して相手に伝えるのは問題ありません。文字数を削るのがそこまで重要だと思われるのであれば、そうすれば良いかと思います。

> ダブルスラッシュが省略するのがデファクトスタンダードになると、正しく解釈するツールも許容範囲になる可能性はあるのではないでしょうか？

これはちょっと文章の意味が分かりません。「正しく解釈するツール」とはなんのことですか？「//の省略をURL仕様通り正しくエラーにするツール」？「//の省略を許容するURL仕様通りでないツール」？
文字通りに理解すると前者ですが、前者は正しいので許容されるのは当たり前です。

(注) なお、URLのホスト名の前後に、ユーザー名、パスワード、ポート番号が付加できますが、話が面倒なのでこの回答では無いものとしています。

この回答へのお礼

あー正直、案2のように解釈される可能性を考慮していませんでした。



私がもし案を出すとすると、

• 『相対URLをhrefに指定する場合は「./ccc.com/ddd.html」のように「./」を省略しない事を推奨。(もし省略されたら自動補完)』　という決まりを定めて、

◦ 『絶対URLのスキームは「http:example.com」のように、ホスト名の前にコロンが付いていたらスキームと解釈する』　という仕様が浮かびました。

• UNCも『相対URLの場合は「.\」を省略しない』(『あるいは\\に代わる別の記号を一文字』) 　という仕様だったら「\\」省略との整合性も取れるのではないでしょうか？

(絶対URLのダブルスラッシュが省略できる代わりに 相対URLの手間が増えましたが、今のURLの仕様を途中から無理矢理に変えると、ちょっと苦し紛れですが…。　絶対URLに重きを置いた場合 こんな案でいかがでしょうか。)



> No.5
> 適当に解釈せずに正しく解釈するツールだとエラーになります。

私はこれをLintのようなツールだと思って、そう返信しました。

つまり、

もし当時SNSなどの影響でダブルスラッシュが省略したURL表記(※)が 仮にデファクトスタンダードになったとして、それもきっかけでURLの仕様の変更に動きがあって、「ダブルスラッシュが省略も許容可能」という仕様になれば、Lintのような正しく解釈するツールも「不正なURLではない」と、ツールにも影響が出るほど大きく変わると思ったのですが。

(※ <a href="https://t.co/RIpbP7n5kH">https:example.com</a> のようにhref内はダブルスラッシュ未省略。)



> 仕様の変更は議論して合意が取れれば可能です。

そうなのですね。もしURLの仕様に変更できる余地が多少あったら、仕様が変わっていた可能性はゼロではないのですね。

もう今更URLの仕様について、ダブルスラッシュの部分から変える事は、慣習的な理由もあってほぼ不可能であるように理解しました。

お礼日時：2025/03/22 00:40

No.10 回答者： k-841 回答日時： 2025/03/19 19:58

＞「短縮URL」というぐらいなら「http://」または「http:」表記で出力されるのが理に適ってると思うのですが、なぜ「https://」が選ばれるようになったのでしょうか？

まず、「//」を省略できないのは世界的な決まりだからで、世界中で共通して使われるネットワーク越しのアドレスであることを明示する表記です。たとえばWindows共有でも、ネットワーク共有先の表記は「\\ホスト名」という表記になっていますが（「\」記号は英語圏では「バックスラッシュ」です）、これと同じような意味です。このような統一表記の方が理に適っており、短縮URLを特別扱いする方がデメリットが大きすぎるのです。

で、なぜhttp://ではなくhttps://になったかというと、ユーザ意識がhttpsの方に向いているからだと思われます。確かに、企業のホームページではいまだに「http://」で表記されているものも見られ（短いという理由というよりは、「えっちてぃーてぃーぴーころんすらっしゅすらっしゅ」という呪文の名残ではないかと思います）、実際にはhttps://にリダイレクトされています。ただ、これだと「セキュリティ意識の低い会社だ」と見られるようになってきているため、最近ではチラシでも最初からhttps://で記載されることが増えてきました。

この回答へのお礼

> このような統一表記の方が理に適っており、短縮URLを特別扱いする方がデメリットが大きすぎるのです。

一旦仕様を当時決めたら、「追加で「http:～ (https:～)」も許容可能」というような仕様にはできないのでしょうか？

お礼日時：2025/03/20 21:01

No.9 回答者： usa3usa 回答日時： 2025/03/18 22:13

No7です

＞URLの仕様を当時決めた人が「http://」について、「スラッシュは2個もいらなかったかも。」という話をどこかで聞きかじった覚えがあるのですが。
＞空想的になってしまうとは思いますが、もし似たような事例があれば用い出して頂くとさらに幸いです。

No7では、「https://」の８バイト文字列が正式な「プロトコル名」と書きましたが、URLは、
　「プロトコル名(https)　：　対象ファイル名」
と理解してもよいと思います。この時の対象ファイル名を絶対パスで指定していると理解できれば、//の意味もわかるのでは？

ーーーーー
ファイルを指定するには、絶対パスと相対パスの2種類がありますよね。
　abc.data
../abc.data
は相対パス
/abc.data
は絶対パスでの指定ですよね。いずれも自分のPC内のファイルです。

それでは、ネットワーク上にあるファイルを指定するにはどうしたらよいのか? ということになって、ルートのさらに上で
　//abc.data
と表記するのがネットワーク上にあるファイルの書き方と私は思いますけどね

この回答へのお礼

https://jp.quora.com/https-%E3%81%AE-%E3%81%AF%E …
一応「http://」のダブルスラッシュの意味を調べてみて出てきた記事です。



> それでは、ネットワーク上にあるファイルを指定するにはどうしたらよいのか?

「//」でホストを表したいのなら、「:」でいいんじゃないでしょうか？

「file:///C:/Users/user/Downloads/」も「file:/C:/Users/user/Downloads/」と表せばいいと思いますし。

「https:host」のように、:の次に英数文字が来ればホスト名 と一目で解釈できなくもないと思いますし。



ダブルスラッシュが省略される仕様が、ある期をきっかけに変わっていても、おかしくなかったと思いますがいかがでしょう？

お礼日時：2025/03/20 21:00

No.8 回答者： tobirisu 回答日時： 2025/03/18 19:14

/が２個多いか少ないかの話ですか？

それが質問の主旨ですか？
2文字多くても少なくても気になりません。
その程度では「もっと短くなった」とは感じません。

この回答へのお礼

> /が２個多いか少ないかの話ですか？

いいえ。

「http://～」が「http:～」の仕様に変わる機会はあった可能性はあったと思いますか？ という質問です。

お礼日時：2025/03/20 20:55

No.7 回答者： usa3usa 回答日時： 2025/03/18 12:01

＞短縮URLは(//を省いた「https:……」のように)もっと短くできるのに、なぜ どこの短縮URLサービスも「https://……」表記で取得されるようにしており、もっとURLを短くしなかったのでしょうか？

https://

というURL形式文字列の中の８バイト文字列が正式な「プロトコル名」だからでしょうね

「https:」という６バイト文字列は（正式な）プロトコル名ではありませんので、No5さんの回答の通り、間違っていても適当に解釈してくれるというのはブラウザなどのツールのおまけ機能です。

ブラウザ内部ではhttps://という８バイト文字列に再解釈してネットアクセスしているはずです。
https://www.marketechlabo.com/url-structure-for- …

仲間内でUSBメモリのことを「USB」と略称で言っても問題ないですが、世の中には多様なUSB機器があるので、公開の場では略称は避けるべきということでしょう。

No.6 回答者： Orange_pk 回答日時： 2025/03/18 08:59

基本的に、もう、今の時代、「https」でないと、WEBブラウザで警告が表示されたり、スムーズにアクセスできなかったりするので、「http」はあり得ないというか、「https」がスタンダードな訳です。

なので、どの企業も、まともな企業なら、「https」を採用しています。

又、「1文字でも短くしたい」と思った時に、「.com」を「.jp」にしても弊害はありませんが、「https」と「http」では機能面で全然違いますので、1文字短くしたいだけで、これを削るのはあり得ないということです。

それだったら、1文字多くても、セキュアで、どんなブラウザでも問題なくスムーズに表示される「https」の方が良い、ということです。

この回答へのお礼

個別な返信が遅れて恐縮です。

No.4(rera1016さん)の回答を見てうっかり気付きましたが、仰る通り「s」の一文字でセキュアになるなら付けた方が良いですね。

お礼日時：2025/03/20 20:53

No.5 回答者： artoo 回答日時： 2025/03/18 01:52

(1) http: か https: か。

例えば、bit.ly だと http: でも、リダイレクトしてくれます。危険性としては、公衆Wifi等で偽のアクセスポイントに繋がった場合、偽APの運営者が
①bit.ly というホスト名を偽のサーバーに繋ぐようなDNSとする
②本物のbit.lyにアクセスしてリダイレクト先のURLを調べる
③それがあらかじめ用意しておいた偽サイトと近しいものであれば、用意しておいた偽サイト（これもhttp:かも）にリダイレクトする
とか出来てしまいます。https:であれば①の段階で証明書のエラーが出ます。もちろん「そんな手の込んだことをする悪人はいないだろうから気にしない」と思うのは個人の自由なので気にしないのは問題ありませんが、それは実際にアクセスする人が決めることであって、短縮URLサービス側が、使う人に対して「そんなリスクをあなたは気にすべきでない」と決めてしまうのはおかしいでしょう。

(2)ホスト名の前の // について
ホスト名の前に // がないのはURLとしては間違っています。間違っていても適当に解釈してくれるというのはブラウザなどのツールのおまけ機能ですね。適当に解釈せずに正しく解釈するツールだとエラーになります。
これも誰が決めるの？という話で、あなたが、一般の短縮URLサービスを使って、自サイトの短縮URLをhttps://bit.ly/※※ と取得したあとで、「自サイトの利用者はメジャーなブラウザから使う人が100%である」と判断して https:bit.ly/※※ と周知するのは状況によっては問題ないかもしれません。
その判断は利用者を知っているあなたがすべきであって、bit.ly等がするのはおかしいでしょうね。「短縮URLサービス」が「URL形式でない文字列」を返すのは変。

この回答へのお礼

個別な返信が遅れて恐縮です。


> (1) http: か https: か。

あー、そのような害意な発想は思い付きませんでした。

「http:」だと、bit.lyなど短縮URL側の信頼や信用にも影響するからなのですね。


> (2)ホスト名の前の // について
> 正しく解釈するツールだとエラーになります。

一旦URLの仕様を当時決めたら、後にダブルスラッシュが省略される仕様が「許容可能」 というような仕様にはできないのでしょうか？

ダブルスラッシュが省略するのがデファクトスタンダードになると、正しく解釈するツールも許容範囲になる可能性はあるのではないでしょうか？

お礼日時：2025/03/20 20:52