http:// の代わりに // を使用する利点は何ですか (アダプティブ https)

//デフォルトプロトコル

/ デフォルト プロトコルの使用は、リソース アクセス プロトコルが現在のページと一致していることを意味します。現在のページが http の場合、アクセスには http プロトコルが使用されます。https の場合、アクセスには https プロトコルが使用されます。このように、http であっても https にアップグレードしてもコードを変更する必要はありません。多くの CDN リソースがこの方法で参照されるようになりました。外部リンクのプロトコル ヘッダーは不確実なため、通常は内部リンクで使用されます。

// はどういう意味ですか?

// はデフォルトのプロトコルです。例:

//jb51.net/css/

デフォルトプロトコルはデフォルトで現在のプロトコルを使用します

現在のページがHTTPの場合、これは

http://jb51.net/css/

現在のページがHTTPSの場合、同等の

https://jb51.net/css/

http:// の代わりに // を使用する条件と利点は何ですか?

現在のページとターゲット リソースは HTTP と HTTPS の両方をサポートしています。http から https へのアップグレード

これの利点は、ユーザーがページを開く方法に応じて、リソース要求プロトコルを適応的に選択できることです。

httpsページのコンテンツについては、ブラウザはデフォルトで非httpsコンテンツを整理し、この状況を回避できます。

// 欠点

デバッグのためにローカルファイルを直接開く場合、使用されるプロトコルはファイルプロトコル（file://）です。

このとき、プロトコルは file://jb51.net/css/ になりますが、これは明らかに存在しません。

現在の Web サイトのプロトコルとの一貫性を保ち、現在のプロトコルに一致するバージョンを迅速にリリースし、SSL またはその他のプロトコル バージョンの導入コストを削減します。開発者は、サーバー クラウドが提供するプロトコルについて心配する必要はなく、// シンボルを使用して最も適切な一致を表すだけで済みます。これは、nodeJS の考え方と一致しています。

利点は次のとおりです。

多くのウェブサイトがhttpからhttpsにアップグレードしたため、これによりウェブサイトがハイジャックされるのを防ぐことができます。初期段階では、変換プロセス中のエラーを回避するために、ジャンプを強制しませんでした。つまり、ユーザーがhttpまたはhttpsにアクセスすると、正常にアクセスできますが、その中のjs、画像、リンクなどはhttpsまたはhttpを使用できません。では、解決策は何でしょうか？解決策は、http：とhttpsを使用せずに、//を使用することです。

//この書き方では、要求したプロトコルに基づいてプロトコルが自動的に追加されます。たとえば、Web サイトが http プロトコルの場合、実際にアクセスするのは http://xxxx です。Web サイトが https プロトコルの場合、要求されるアドレスは https://xxxx になります。http://xxx と記述すると、Web サイトが https オンラインでセキュリティ警告が表示される場合があり、一部のブラウザーではページを正常に読み込めない場合があります。 https と直接記述すると、ローカル開発は http であることがわかるはずです...

以下は知乎からの典型的な返答である。

多くの人がメリットについての質問に答えています。もちろん、このメリットは https にアップグレードすることで最も実感できます。私は、以前の人々がこのように書かなかった理由を単に付け加えているだけです。もちろん、これをどのように書くかを知らないフロントエンド開発者は確かにたくさんいます。しかし、これを知っていても、おそらくこのように書くことはできないでしょう。 UC ブラウザの以前のバージョンの多くはこの記述方法をサポートしていないため、//ab/ は直接 /ab/ として認識されます。つまり、http://example.com ページに //example-cdn.net/static-file というアドレスを記述すると、UC は実際には http://example.com/example-cdn.net/static-file にアクセスします。 UC の過去の市場シェアは誰もが知っています。それで……

「サイト全体の HTTPS アップグレード」を行っていないことが一目でわかります。サイト全体を HTTPS にアップグレードしたとき、私は本当に http:// と書く人を全員殺したいと思いました。特に、データベース内のリンクと JS で結合された URL です。プロセス中にはさまざまな正規表現が使用され、手動による検証も必要でした。残念ながら、http:// と書くプログラマーが多すぎるので、諦めるしかありません。コメントで理由を尋ねた人がいました。理由は、すべて // と記述すると、データベース内のデータとソースコードを変更する必要がなくなり、直接 https をアップグレードできるからです。 https 化は滅多に起こらないと言う人もいるかもしれません。偶然にも、私は Tencent と Alibaba の両方で https 化に遭遇しました。Alibaba にいた頃、私は 1688 Web サイト全体のフロントエンド コード変換を担当していました (各部門が独自に変換していました) (HTML だけでなく、CSS、JS、Velocity テンプレートなども! 本当に汚くて疲れる仕事でした。どうして私がこの仕事を引き受けなければならないのでしょうか?)。http:// と書いた人を何度叱ったと思いますか?フロントエンド開発者の中には、JS で http を直接記述する人もいます。現在のページのプロトコルを使用すると死んでしまうのでしょうか?

一部のフロントエンドでは、正規表現を使用して URL を判断するときに、http:// と https:// のみを受け入れ、// は受け入れません。これは本当に常識に欠けています。プログラマーが多すぎる、愚かすぎる。あるいは、単に HTTPS について聞いたことがないだけかもしれません。まだ理解できない場合は、いくつか質問させてください。http:// を使用する場合、現在のページは http プロトコルを使用していると想定しています。フロントエンド開発者として、現在のページのプロトコルをどのように判断できますか? http リンクは https ページでエラーを報告することをご存知ですか?現在のページのプロトコルを使用する必要があるため、// を記述する必要があります。https:// を使用すると、同じ問題が発生します。3 年後に https:// が存在するかどうかをどうやって知るのですか? その場合、すべてを https:// に変更しますか?明らかに間違った仮定はしないでください。現在のページがどのプロトコルで開かれるかさえわかりません。したがって、// を使用する必要があります。同様の誤った思い込みは数多くあります。たとえば、多くの中国のプログラマーは、電話番号には文字は含まれず、数字と括弧のみが含まれていると考えています。本当にそうなのでしょうか？

世界的な置き換えで十分だと言う人もいますが?たとえば、Taobao が https にアップグレードする予定なので、すべての http:// を // に置き換えたとします。最初のバグ: <a href="http://tmail.com"> を <a href="//tmail.com"> に置き換えましたが、http://tmail.com は当時 https をサポートしていなかったため、特定の範囲内のドメイン名 http://(taobao|taobao2|taobao3).com を //$1.com に置き換えました。2 番目のバグ: 一部の JS は url = "http://" + location.hostname + '/' + path のように記述され、一部の JS は /^http:\/\//.test(input) のように記述されます。これには正規表現は使えないとおっしゃいました。すべての JS で http をグローバルに検索し、手動で確認してください。 Taobao には JS ファイルがいくつあるかご存知ですか? これらのファイルは 10 年間キャッシュされます。変更しても更新されない可能性があります。そして、もしミスをしてユーザーの注文に影響を与えた場合、ジャック・マーに1億円の損失を補償する余裕はあるのでしょうか？ 3 番目のバグ: 一部のデータはコード内に存在せず、データベース内に存在します。たとえば、user.image の値は http で始まります。そのため、user.image を user.image.replace('http://', '//') と記述するか、データベース内のデータを直接変更します (データ量が多い場合、これは基本的に不可能です)。 4 番目のバグ: nginx とクロスドメインでドメイン名を変更するのを忘れました。 5 番目のバグ: 構成システムで base_url を変更するのを忘れました。 6 番目のバグ: https ページに外部の http iframe が埋め込まれています... 泣くばかりです。これは解決が難しいです。 運が良ければ、// (https の外部サポート) に変更するだけです。 運が悪ければ、ページ ロジックを変更する必要があります。 N 番目のバグ... HTTPS のアップグレードは面倒で疲れる作業です。簡単だと言って実行しますが、実際に始めると、どれだけ多くの作業が関係しているかがわかります。最善の解決策は、現在のページをたどったり、変数を使用したりして、プロトコルを簡単に変更できるようにすることです。いずれにしても、http:// をハードコードするのは決して良い考えではありません。一部のプログラマーは、HTTPS が存在することは知っていても、コードを書くときに互換性を持たせようとせず、「2 年後にこの会社を辞めるが、HTTPS はまだ少なくとも 3 年間は存在するだろう」と考え、ゴミコードを書きます。

ファイルをリンクするときに、http:// の代わりに // を使用する開発者が増えています。たとえば、< a href="http://jb51.net... は通常、< a href = " //http://jb51.net... と記述されます。これと従来の http の違いは何でしょうか。

元々、あなたのウェブサイトは http で、すべての src は http で始まっていました。ひどい運営者に乗っ取られたのかと思いきや、あなたのページには子供にはふさわしくないコンテンツや純粋な広告が大量に掲載されていました。誰かが、https に置き換えるとこの問題は改善できると教えてくれました。この時点で、以前の src と ajax で http:// の代わりに // を記述するのがいかに賢明だったかがわかるでしょう。 。 。

朱朗CMS公式

オープンソースやクラウド プラットフォームがますます登場し、SSL プロトコルが広く導入されるようになったため (たとえば、Zhulang CMS では SSL プロトコルのサポートが完全に有効化されています)、開発時に http プロトコルの選択と識別に直面することになりました。周知のとおり、SSL 参照が多すぎると通常のサイトの効率が低下する可能性がありますが、この目的のために純粋な SSL バージョンを再設計することはできません。オープンソース ライブラリに関しては、一般的なプラットフォームでは SSL バージョンと非 SSL バージョンの両方が提供されています。たとえば、次の 2 つのライブラリ: https://code.z01.com/js/jquery-3.2.1.slim.min.jshttp://code.z01.com/js/jquery-3.2.1.slim.min.js の参照効果は一貫しています。そのため、開発者は「//URL/file」メソッドを直接使用して以前のプロトコルを置き換え、自動的に認識できるようにします。つまり、SSL プロトコルであろうと通常の http プロトコルであろうと、ブラウザが自動的に識別し、現在のサイトと自動的に一致させることで、最適なセキュリティ要求と最も効率的な読み込み方法を実現します。つまり、これは開発方法と開発の考え方です。クラウド コンピューティングにおける Web およびモバイル開発は、日々強力になっています。