대신 //를 사용하면 장점이 있습니다.

//기본 프로토콜

/기본 프로토콜을 사용한다는 것은 리소스 액세스에 대한 프로토콜이 현재 페이지와 일치한다는 것을 의미합니다. http인 경우 액세스에 http 프로토콜을 사용합니다. 액세스를 위한 https 프로토콜입니다. 이렇게 하면 http이든 https로 업그레이드하든 코드를 변경할 필요가 없습니다. 이제 많은 CDN 리소스가 이러한 방식으로 참조됩니다. 외부 링크의 프로토콜 헤더가 불확실하기 때문에 일반적으로 내부 링크에서 사용됩니다.

국내 사업자 등의 대규모 하이재킹으로 인해 웹사이트 방문 시 저속한 광고가 다수 삽입되어 사용자 경험이 저하되고 있으므로, 주요 검색 엔진에서는 해당 사이트를 https로 전환하기 위해 최선을 다하시기를 바랍니다. method

// 무슨 뜻인가요?

//는 기본 프로토콜을 작성하는 방법입니다. 예를 들어

//jb51.net/css///jb51.net/css/

缺省协议默认使用当前协议

当前页面为HTTP时，等效

http://jb51.net/css/

当前页面为HTTPS时，等效

https://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/가 됩니다. 분명히 존재하지 않습니다

현재 웹사이트 프로토콜과 일관성을 유지하고, 현재와 일치하는 버전을 빠르게 출시하세요. 프로토콜을 사용하고 SSL 또는 기타 프로토콜 버전의 배포 비용을 줄입니다. 개발자는 서버 클라우드에서 어떤 프로토콜을 제공하는지 걱정할 필요가 없습니다. 가장 적합한 일치를 나타내기 위해 // 기호만 사용하면 됩니다. 이는 nodeJS의 생각과 일치합니다.

장점은 다음과 같습니다.

많은 웹사이트에서 http를 https로 업그레이드했기 때문에 초기 단계에서 변환 과정에서 실수를 저지르지 않도록 강제로 점프하지 않았습니다. 즉, 사용자가 http 또는 https에 액세스하면 정상적으로 액세스할 수 있지만 내부의 js, 그림, 링크 등은 https 또는 http를 사용할 수 없습니다. 그렇다면 해결 방법은 http 대신 //를 사용하는 것입니다. 그리고 https입니다.

//이러한 작성 방법은 요청한 프로토콜을 기반으로 프로토콜을 자동으로 추가합니다. 예를 들어, 귀하의 웹 사이트는 http 프로토콜을 사용하므로 실제로 액세스하는 주소는 http://xxxx입니다. 귀하의 웹 사이트가 https 프로토콜을 사용하는 경우 http를 입력하면 요청된 주소는 https://xxxx가 됩니다. //xxx. 그런 다음 웹 사이트가 https 온라인인 경우 보안 경고가 보고될 수 있으며 일부 브라우저에서는 페이지를 정상적으로 로드하지 못할 수도 있습니다. https를 직접 쓰시면 로컬 개발이 http라는 걸 아셔야 합니다...

다음 내용은 Zhihu

🎜🎜Benefits의 몇 가지 고전적인 답변입니다. 많은 분들이 답변해 주셨습니다. 이 이점은 확실히 https로 업그레이드할 때 가장 많이 느껴집니다. 전임자들이 이렇게 쓰지 않은 이유를 덧붙일 뿐입니다. 물론 이런 글쓰기 방식을 모르는 프론트엔드가 실제로 많습니다. 하지만, 알고 있더라도 아마 이렇게 쓸 수는 없을 것입니다. UC 브라우저의 이전 버전에서는 이 쓰기 방식을 지원하지 않는 경우가 많기 때문에 //a.b/는 바로 /a.b/로 이해됩니다. 즉, 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 웹사이트의 프런트엔드 코드 변환을 담당했습니다(개별 부서에서 자체 수정). (HTML뿐만 아니라 CSS, JS, Velocity 템플릿 등도 있습니다. 그냥 더러운 일인데 도대체 내가 왜 이 일을 맡았나요?) http:// 쓴 사람을 몇 번이나 혼냈는지 맞춰보세요. 일부 프런트엔드는 JS에서 직접 http를 작성하기도 합니다. 현재 페이지의 프로토콜을 계속 사용하면 죽을까요? 🎜🎜🎜

일부 프런트엔드는 실제로 http:// 및 https://만 허용하지만 정규식을 사용하여 URL을 판단할 때는 //를 허용하지 않습니다. 이는 실제로 상식이 부족합니다. 프로그래머가 너무 많고, 너무 늦습니다. 아니면 단지 HTTPS에 대해 들어본 적이 없기 때문일 수도 있습니다. 그래도 이해가 안 되시면 몇 가지 질문을 드리겠습니다. http://를 사용한다면 기본적으로 http 프로토콜을 사용하는 현재 페이지로 설정됩니다. 왜 프런트엔드인 당신이 프로토콜을 결정합니까? 현재 페이지? http 링크가 https 페이지에서 오류를 보고한다는 사실을 모르시나요? 현재 페이지의 프로토콜을 계속 사용해야 하므로 //https://를 사용해도 같은 문제입니다. 3년 후에 https://가 있을지 어떻게 알 수 있나요? 그때까지 모든 것을 https://로 바꾸실 건가요? 명백히 잘못된 가정은 하지 마세요! 현재 페이지가 어떤 프로토콜로 열릴지 전혀 알 수 없습니다! 따라서 // 아! 예를 들어, 많은 중국 프로그래머들은 전화번호에는 문자가 아닌 숫자와 괄호만 포함되어 있다고 믿습니다. 이것이 실제로 사실입니까?

글로벌 교체만으로는 충분하지 않다고 말하는 사람들도 있나요? 예를 들어, Taobao가 https를 업그레이드하려고 하고 모든 http://를 //첫 번째 버그로 교체한다고 가정합니다. /tmail.com"> 그런데 당시 http://tmail.com은 https를 지원하지 않았기 때문에 특정 범위 내의 도메인 이름을 http://(taobao|taobao2|taobao3).com으로 바꾸었습니다. // $1.com 두 번째 버그: 일부 JS는 다음과 같이 작성됩니다. url = "http://" + location.hostname + '/' + path, 일부 JS는 다음과 같이 작성됩니다. /^http:/// .test(input) . 정규식을 사용할 수 있는 방법이 없다고 말씀하셨습니다. 모든 JS에서 전역적으로 http를 검색한 다음 수동으로 검토하세요. 타오바오에 JS 파일이 몇 개나 있는지 아시나요... 그리고 이 파일들은 10년 동안 캐시되어 있었는데... 변경하더라도 업데이트가 되지 않을 수도 있습니다. 그리고 실수를 해서 사용자의 주문에 영향을 미치면 Jack Ma의 1억 손실을 지불할 여유가 있습니까? 세 번째 버그: 일부 데이터는 코드에 전혀 없지만 데이터베이스에 있습니다. 예를 들어 user.image의 값은 http로 시작합니다. 그래서 user.image를 user.image.replace('http://', ​​​​'//')로 작성하거나, 데이터베이스에 있는 데이터를 직접 변경하는 경우(데이터의 양이 많은 경우 기본적으로 불가능합니다) 네 가지 버그: nginx 및 crossdomain에서 도메인 이름을 변경하는 것을 잊었습니다. 다섯 번째 버그: 구성 시스템에서 base_url을 변경하는 것을 잊었습니다. 여섯 번째 버그: https 페이지에 외부 http iframe이 포함되어 있습니다. 이는 해결하기 어렵습니다. 운이 좋으면 //로 변경하면 됩니다(https에 대한 외부 지원이면 충분합니다). 운이 좋지 않으면 페이지 로직을 변경해야 합니다. N번째 버그... HTTPS 업그레이드는 쉽다고 하면 하게 됩니다. 가장 좋은 해결책은 현재 페이지를 따르거나 변수를 사용하는 등 프로토콜을 쉽게 변경할 수 있도록 만드는 것입니다. 어쨌든 http://를 하드코딩하는 것은 좋지 않습니다. 일부 프로그래머는 코드를 작성할 때 HTTPS가 가능하다는 것을 분명히 알지만 호환 가능하게 만들지는 않습니다. 그들은 "2년 후에 이 회사를 떠날 것이고 HTTPS는 적어도 3년은 더 있을 것이다"라고 생각합니다.

파일을 링크할 때 http:// 대신 //를 사용하는 개발자가 늘어나고 있습니다. 즉,

원래 귀하의 웹사이트는 http였고 모든 src는 http로 시작했습니다. 귀하의 페이지가 어린이에게 적합하지 않은 콘텐츠와 순수 광고로 가득 차 있을 때 누군가가 저에게 말했습니다. https를 대체하면 이 문제를 개선할 수 있습니다. 그러면 이전 src와 ajax를 http:// 대신 // 작성한 것이 얼마나 현명한 결정인지 알게 될 것입니다. . .

Zhulang CMS 공식

오픈 소스 및 클라우드 플랫폼이 점점 더 많이 등장하고 SSL 프로토콜이 널리 도입됨에 따라(예: Zhulang CMS는 SSL 프로토콜 지원을 완전히 지원함) 사람들은 Selection 및 Cloud 플랫폼을 개발할 때 문제에 직면하게 되었습니다. http 프로토콜 식별. 우리 모두 알고 있듯이 SSL 참조가 너무 많으면 일반 사이트의 비효율성이 발생할 수 있지만 이러한 이유로 순수 SSL 버전을 다시 설계할 수는 없습니다. 오픈 소스 라이브러리에 표시된 것처럼 대부분의 플랫폼은 SSL 및 비SSL 버전을 모두 제공합니다. 예를 들어 다음 두 라이브러리는 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 프로토콜이든 브라우저가 현재 사이트를 자동으로 식별하고 자동으로 일치시켜 최상의 보안 요청과 가장 효율적인 로딩 방법을 달성합니다. 한마디로 이것이 개발방식이자 개발사고이며, 클라우드컴퓨팅 웹과 모바일 개발이 나날이 성장하고 있는 것입니다.

관련 추천:

thinkPHP 개발(http://w2ks.com)

위 내용은 대신 //를 사용하면 장점이 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!