Vorteile der Verwendung von // anstelle von

//Standardprotokoll

/Die Verwendung des Standardprotokolls bedeutet, dass das Protokoll für den Ressourcenzugriff mit der aktuellen Seite übereinstimmt. Wenn die aktuelle Seite http ist, verwenden Sie http Protokoll, um darauf zuzugreifen. Wenn es https ist, verwenden Sie das https-Protokoll, um darauf zuzugreifen. Auf diese Weise muss der Code nicht geändert werden, unabhängig davon, ob es sich um http oder ein Upgrade auf https handelt. Jetzt werden viele CDN-Ressourcen auf diese Weise zitiert. Es wird im Allgemeinen in internen Links verwendet, da der Protokollheader externer Links unsicher ist.

Aufgrund der massiven Manipulation durch inländische Betreiber usw. schalten Menschen beim Besuch von Websites eine große Anzahl vulgärer Werbung ein, was das Benutzererlebnis beeinträchtigt. Daher hoffen die großen Suchmaschinen, dass jeder sein Bestes geben wird, um die Website zu konvertieren zur https-Methode

//Was bedeutet das?

// ist die Möglichkeit, das Standardprotokoll zu schreiben, zum Beispiel

//jb51.net/css/

Das Standardprotokoll verwendet standardmäßig das aktuelle Protokoll

Die aktuelle Seite ist HTTP und entspricht

http://jb51.net/css/

Wenn die aktuelle Seite HTTPS ist, entspricht sie

https://jb51.net/css/

Verwenden Sie stattdessen //. Was sind die Bedingungen und Vorteile von http://?

Die aktuelle Seite und die Zielressource unterstützen sowohl HTTP als auch HTTPS und werden von http auf https aktualisiert

Der Vorteil besteht darin, dass das Anforderungsprotokoll der Ressource entsprechend adaptiv ausgewählt werden kann auf die Art und Weise, wie der Benutzer die Seite öffnet,

Für den Inhalt von https-Seiten organisiert der Browser standardmäßig Nicht-https-Inhalte, wodurch diese Situation vermieden werden kann

// Nachteile

Direkt öffnen Beim Debuggen lokaler Dateien wird als Protokoll das Dateiprotokoll (file://) verwendet

Zu diesem Zeitpunkt wird das Protokoll zu file://jb51. net/css/, das offensichtlich nicht existiert

Seien Sie konsistent mit dem aktuellen Website-Protokoll, veröffentlichen Sie schnell eine Version, die Ihrem aktuellen Protokoll entspricht, und reduzieren Sie die Bereitstellungskosten von SSL oder anderen Protokollversionen. Entwickler müssen sich keine Gedanken darüber machen, welche Protokolle von der Server-Cloud bereitgestellt werden. Sie müssen lediglich das //-Symbol verwenden, um die am besten geeignete Übereinstimmung darzustellen.

Die Vorteile sind wie folgt:

Da viele Websites http auf https aktualisiert haben, kann verhindert werden, dass unsere URL gekapert wird, um einen Fehler zu machen Der Konvertierungsprozess befindet sich im Anfangsstadium. Wir haben keinen erzwungenen Sprung. Das heißt, wenn Benutzer auf http oder https zugreifen, können sie normal darauf zugreifen, aber die darin enthaltenen JS, Bilder, Links usw. können weder https noch http verwenden ist die Lösung? Die Lösung besteht darin, // zu verwenden, nicht http: und https mitzubringen, und das war's.

//Diese Schreibweise fügt automatisch ein Protokoll hinzu, das auf dem von Ihnen angeforderten Protokoll basiert. Beispiel: Ihre Website verwendet das http-Protokoll. Sie greifen also tatsächlich auf http://xxxx zu. Wenn Ihre Website das https-Protokoll verwendet, wird die angeforderte Adresse zu https://xxxx. Sie wissen, wenn Sie http schreiben: //xxx. Wenn Ihre Website dann online ist, wird möglicherweise eine Sicherheitswarnung gemeldet und einige Browser können die Seite möglicherweise nicht einmal normal laden. Wenn Sie https direkt schreiben, müssen Sie wissen, dass die lokale Entwicklung http ist...

Der folgende Inhalt enthält einige klassische Antworten von Zhihu

Die Vorteile werden von vielen Menschen beantwortet . Dieser Vorteil macht sich sicherlich am deutlichsten beim Upgrade auf https bemerkbar. Ich füge nur einen Grund hinzu, warum Vorgänger nicht so geschrieben haben. Natürlich gibt es tatsächlich viele Frontends, die diese Schreibweise nicht kennen. Aber selbst wenn Sie es wüssten, könnten Sie es wahrscheinlich nicht so schreiben. Da viele frühere Versionen von UC Browser diese Schreibmethode nicht unterstützen, wird //a.b/ direkt als /a.b/ verstanden. Das heißt, wenn Sie //example auf der Seite von http://example.com schreiben -. Die Adresse von cdn.net/static-file, UC greift tatsächlich auf http://example.com/example-cdn.net/static-file zu. Jeder kennt den bisherigen Marktanteil von UC. Also...

Auf den ersten Blick sieht es so aus, als hätten Sie kein „standortweites HTTPS-Upgrade“ durchgeführt. Als ich die gesamte Website auf HTTPS aktualisiert habe, wollte ich unbedingt die Person töten, die http:// geschrieben hat. Insbesondere die Links in der Datenbank und die in JS zusammengefügten URLs. In diesem Zeitraum wurden verschiedene reguläre Regeln angewendet und eine manuelle Überprüfung war erforderlich. Es gab jedoch zu viele Programmierer, die http:// schrieben, sodass ihnen keine andere Wahl blieb, als aufzugeben. Einige Leute haben in den Kommentaren auch nach dem Grund gefragt. Der Grund ist, dass ich die Daten und den Quellcode in der Datenbank nicht ändern muss, wenn ich sie vollständig schreibe. Man kann sagen, dass eine https-Transformation selten vorkommt. Ich bin sowohl bei Tencent als auch bei Alibaba auf eine https-Transformation gestoßen. Als ich bei Alibaba war, war ich für die Front-End-Code-Transformation der gesamten 1688-Website verantwortlich. (Nicht nur HTML, sondern auch CSS, JS, Velocity-Vorlagen usw. Es ist nur Drecksarbeit, warum zum Teufel habe ich diesen Job angenommen?) Ratet mal, wie oft ich die Person gescholten habe, die http:// geschrieben hat? Einige Frontends schreiben http auch direkt in JS. Werden Sie sterben, wenn Sie weiterhin das Protokoll der aktuellen Seite verwenden?

Einige Frontends akzeptieren tatsächlich nur http:// und https://, aber nicht //, wenn reguläre Ausdrücke zur Beurteilung von URLs verwendet werden. Dies ist wirklich ein Mangel an gesundem Menschenverstand. Zu viele Programmierer, zu zurückgeblieben. Oder vielleicht liegt es einfach daran, dass sie noch nie von HTTPS gehört haben. Wenn Sie es immer noch nicht verstehen, möchte ich Ihnen ein paar Fragen stellen: Wenn Sie http:// verwenden, verwenden Sie standardmäßig das http-Protokoll, um zur aktuellen Seite zu gelangen. Warum entscheiden Sie als Frontend über das Protokoll? aktuelle Seite? Wussten Sie nicht, dass HTTP-Links Fehler auf https-Seiten melden? Sie sollten weiterhin das Protokoll der aktuellen Seite verwenden, also müssen Sie schreiben //Wenn Sie https:// verwenden, ist es das gleiche Problem. Woher wissen Sie, ob es in drei Jahren ein https:// geben wird? Werden Sie bis dahin alles in https:// ändern? Machen Sie keine Annahmen, die offensichtlich falsch sind! Sie haben keine Ahnung, mit welchem ​​Protokoll die aktuelle Seite geöffnet wird! Sie müssen also // Ah! verwenden. Es gibt viele ähnliche falsche Annahmen. Beispielsweise glauben viele chinesische Programmierer, dass Telefonnummern nur Zahlen und Klammern enthalten, keine Buchstaben. Ist das wirklich so?

Jemand hat gesagt, dass globaler Ersatz nicht ausreicht? Angenommen, Taobao möchte https aktualisieren und Sie ersetzen alle http:// durch //Der erste Fehler: Sie ersetzen /tmail.com">, aber zu diesem Zeitpunkt unterstützte http://tmail.com https nicht, sodass Sie den Domänennamen innerhalb eines bestimmten Bereichs ersetzt haben: http://(taobao|taobao2|taobao3).com // $1.com zweiter Fehler: Einige JS sind so geschrieben: url = "http://" + location.hostname + '/' + path, und einige JS sind so geschrieben /^http:/// .test(input) . Sie sagten, dass es keine Möglichkeit gibt, reguläre Ausdrücke global in allen JS zu verwenden und sie dann manuell zu überprüfen. Wissen Sie, wie viele JS-Dateien es auf Taobao gibt ... Und diese Dateien wurden zehn Jahre lang zwischengespeichert ... Selbst wenn Sie sie ändern, werden sie möglicherweise nicht aktualisiert. Und wenn Sie einen Fehler machen und die Bestellungen der Benutzer beeinträchtigen, können Sie es sich dann leisten, den Verlust von Jack Ma in Höhe von 100 Millionen zu bezahlen? Der dritte Fehler: Einige Daten befinden sich überhaupt nicht im Code, sondern in der Datenbank. Beispielsweise beginnt der Wert von user.image mit http. Sie schreiben also user.image als user.image.replace('http://', ​​​​'//') oder ändern die Daten direkt in der Datenbank (bei großen Datenmengen ist dies grundsätzlich unmöglich). . Vier Fehler: Sie haben vergessen, den Domainnamen in Nginx und Crossdomain zu ändern. Der sechste Fehler: Ihre https-Seite bettet einen externen http-Iframe ein. Wenn Sie Glück haben, ändern Sie es einfach in // (externe Unterstützung für https reicht aus). Wenn Sie kein Glück haben, müssen Sie die Seitenlogik ändern. Der N-te Fehler... HTTPS-Upgrade ist eine schmutzige Aufgabe. Wenn Sie sagen, dass es einfach ist, werden Sie es tun. Sobald Sie damit beginnen, werden Sie wissen, wie viele Dinge damit verbunden sind. Die beste Lösung besteht darin, das Protokoll einfach zu ändern, z. B. der aktuellen Seite zu folgen oder Variablen zu verwenden. Es ist definitiv nicht gut, http:// fest zu codieren. Wenn einige Programmierer Code schreiben, wissen sie offensichtlich, dass HTTPS verfügbar ist, machen ihn aber nicht kompatibel. Sie denken: „Ich werde dieses Unternehmen nach zwei Jahren verlassen, und HTTPS wird noch mindestens drei Jahre lang schreiben.“

Immer mehr Entwickler verwenden beim Verknüpfen von Dateien // anstelle von http://, z. B.

Ursprünglich war Ihre Website http, und alle Quellen begannen mit http. Ich dachte, sie sei von beschissenen Betreibern gekapert und mit einer Menge Inhalten vollgestopft worden, die für Kinder ungeeignet sind/und manchmal reine Werbung Sie wissen, dass das Ersetzen von https dieses Problem verbessern kann. Dann wissen Sie, was für eine kluge Entscheidung es war, dass die vorherigen src und ajax als // statt http:// geschrieben wurden. . .

Offizieller Zhulang CMS

Mit dem Aufkommen von immer mehr Open-Source- und Cloud-Plattformen und der weit verbreiteten Einführung von SSL-Protokollen (wie z. B. Zhulang CMS hat das SSL-Protokoll vollständig aktiviert Unterstützung), müssen sich die Leute bei der Entwicklung mit der Wahl und Identifizierung des http-Protokolls auseinandersetzen. Wie wir alle wissen, können zu viele SSL-Referenzen zur Ineffizienz gewöhnlicher Websites führen. Aus diesem Grund können wir jedoch keine reine SSL-Version neu entwerfen. Wie in Open-Source-Bibliotheken gezeigt, bieten die meisten Plattformen sowohl SSL- als auch Nicht-SSL-Versionen an. Wie zum Beispiel diese beiden Bibliotheken: https://code.z01.com/js/jquery-3.2.1.slim.min.jshttp://code.z01.com/js/jquery-3.2.1.slim.min. Der Referenzeffekt von js ist konsistent. Daher verwenden Entwickler direkt die Methode „//URL/File“, um das vorherige Protokoll zu ersetzen, damit es automatisch erkannt werden kann. Das heißt, unabhängig davon, ob es sich um das SSL-Protokoll oder das normale HTTP-Protokoll handelt, bleibt es dem Browser überlassen, die aktuelle Site automatisch zu identifizieren und abzugleichen, wodurch die beste sichere Anfrage und die effizienteste Lademethode erreicht werden. Kurz gesagt, dies ist eine Entwicklungsmethode und ein Entwicklungsdenken, und die Cloud-Computing-Web- und Mobilentwicklung nimmt von Tag zu Tag zu.

Verwandte Empfehlungen:

thinkPHP development (http://w2ks.com)

Das obige ist der detaillierte Inhalt vonVorteile der Verwendung von // anstelle von. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!