답변:
일반적으로 상대 URL을 사용하는 것이 가장 좋은 방법으로 간주되므로 웹 사이트가 현재 배포 된 기본 URL에 바인딩되지 않습니다. 예를 들어, 수정하지 않고 공개 호스트뿐만 아니라 로컬 호스트에서도 작업 할 수 있습니다.
절대 URL로 구성표 (예 : http / https) 및 호스트 이름 (예 : yourdomain.com)을 포함한 URL을 유지하지 않으면 로컬 리소스의 경우 유지 관리 및 디버그가 끔찍하기 때문에 그렇게하지 않습니다 (로컬 리소스의 경우).
코드의 어느 곳에서나 절대 URL을 사용했다고 가정 해 봅시다 <img src="http://yourdomain.com/images/example.png">. 이제 당신이 갈 때 일어날 일 :
첫 번째 예에서는 페이지에서 안전하지 않은 콘텐츠가 요청되었다는 경고 메시지가 표시됩니다. 모든 URL이 http (: //yourdomain.com/images/example.png)를 사용하도록 하드 코딩되었으므로 그리고 https를 통해 페이지를 실행할 때 브라우저는 정보 유출을 방지하기 위해 모든 리소스가 https를 통해로드 될 것으로 예상합니다.
두 번째 예에서 사이트를 테스트 환경에서 라이브로 배치하면 모든 리소스가 여전히 라이브 도메인 대신 테스트 도메인을 가리키고 있음을 의미합니다.
따라서 절대 또는 상대 URL을 사용할 지에 대한 질문에 대답하려면 항상 상대 URL (로컬 리소스의 경우)을 사용하십시오.
먼저 사용할 수있는 다양한 유형의 URL을 살펴 보겠습니다.
http://yourdomain.com/images/example.png//yourdomain.com/images/example.png/images/example.pngimages/example.png아래 예제에서 웹 사이트가 서버의 다음 위치에서 실행되고 있다고 가정합니다 /var/www/mywebsite.
http://yourdomain.com/images/example.png
위의 (절대) URL이 리소스에 액세스하려고합니다 /var/www/website/images/example.png. 이 유형의 URL은 위에서 설명한 이유로 자신의 웹 사이트에서 리소스를 요청하기 위해 항상 피하고 싶은 것 입니다. 그러나 그 자리가 있습니다. 예를 들어 웹 사이트가 http://yourdomain.com있고 https를 통해 외부 도메인에서 리소스를 요청하려는 경우이를 사용해야합니다. 예 https://externalsite.com/path/to/image.png.
//yourdomain.com/images/example.png
이 URL은 사용 된 현재 체계를 기반으로하며 외부 리소스 (이미지, 자바 스크립트 등)를 포함 할 때 거의 항상 사용해야합니다.
이 유형의 URL은 현재 페이지 구성표를 사용합니다. 이는 귀하가 페이지에 http://yourdomain.com있고 해당 페이지에 이미지 <img src="//yourdomain.com/images/example.png">의 URL이에서 확인할 이미지 태그임을 의미합니다 http://yourdomain.com/images/example.png.
페이지에 http**s**://yourdomain.com있고 해당 페이지에 이미지 태그가 있으면 이미지 <img src="//yourdomain.com/images/example.png">의 URL이에서 확인됩니다 https://yourdomain.com/images/example.png.
이것은이 필요하지 않을 때 HTTPS를 통해로드 자원을 방지하고이 때 자동으로 HTTPS를 통해 확인 리소스를 요청하게 됩니다 필요합니다.
위 URL은 서버 측에서 이전 URL과 동일한 방식으로 해결됩니다.
위의 (절대) URL이 리소스에 액세스하려고합니다
/var/www/website/images/example.png.
/images/example.png
지역 자원의 경우이를 참조하는 선호되는 방법입니다. /var/www/mywebsite웹 사이트 의 문서 루트 ( )를 기반으로하는 상대 URL 입니다. 이것은 당신이 <img src="/images/example.png">그것을 가지고있을 때 항상 해결 될 것을 의미 합니다 /var/www/mywebsite/images/example.png.
어느 시점에서 도메인을 전환하기로 결정한 경우 도메인이 상대적이기 때문에 여전히 작동합니다.
images/example.png
이전 URL과 조금 다르지만 상대 URL이기도합니다. 이 URL은 현재 경로와 관련이 있습니다. 이것이 의미하는 바는 사이트의 위치에 따라 다른 경로로 해석된다는 것입니다.
예를 들어 페이지에 있고 페이지 http://yourdomain.com를 사용 <img src="images/example.png">하는 경우 서버에서 /var/www/mywebsite/images/example.png예상대로 해결 되지만 페이지에 http://yourdomain.com/some/path있고 정확히 동일한 이미지 태그를 사용하면 갑자기 해결됩니다 /var/www/mywebsite/some/path/images/example.png.
외부 리소스를 요청할 때 스키마를 상대적으로 강요하지 않는 한 스키마와 관련된 URL을 사용하고 로컬 리소스를 처리 할 때 문서 루트를 기준으로 상대 URL을 사용하려고합니다.
예제 문서 :
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
<link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
<link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
</head>
<body>
<img src="/images/some/localimage.png" alt="">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
</body>
</html>다음을 참조하십시오 : http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
foo://username:password@example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ / \________________/\_________/ \__/ \___/ \_/ \_________/ \_________/ \__/
| | | | | | | | |
| userinfo hostname port | | parameter query fragment
| \_______________________________/ \_____________|____|____________/
scheme | | | |
| authority |path|
| | |
| path interpretable as filename
| ___________|____________ |
/ \ / \ |
urn:example:animal:ferret:nose interpretable as extension절대 URL은 "경로"부분 앞에있는 부분을 포함합니다. 즉, 구성표 ( httpin http://foo/bar/baz) 및 호스트 이름 ( fooin in http://foo/bar/baz) (및 선택적으로 port, userinfo 및 port)이 포함됩니다.
상대 URL은 경로로 시작합니다.
절대 URL은 절대적입니다. 리소스의 위치는 URL 자체 만보고 확인할 수 있습니다. 상대 URL은 불완전합니다.이를 해결하려면 체계와 호스트 이름이 필요하며 일반적으로 현재 컨텍스트에서 가져옵니다. 예를 들어 웹 페이지의
http://myhost/mypath/myresource1.html당신은 그렇게 링크를 넣을 수 있습니다
<a href="pages/page1">click me</a>href링크 의 속성에서 상대 URL이 사용되며 클릭하면 해당 URL을 확인하기 위해 해결해야합니다. 이 경우 현재 컨텍스트는
http://myhost/mypath/myresource1.html따라서 스키마, 호스트 이름 및 이들의 주요 경로를 가져와 앞에 추가 pages/page1하여
http://myhost/mypath/pages/page1링크가 다음과 같을 경우 :
<a href="/pages/page1">click me</a>( /URL 시작 부분에 표시됨) 다음과 같이 해결되었을 것입니다.
http://myhost/pages/page1선행 /은 호스트의 루트를 나타 내기 때문 입니다.
웹 응용 프로그램에서는 앱에 속한 모든 리소스에 상대 URL을 사용하는 것이 좋습니다. 이렇게하면 페이지 위치를 변경해도 모든 것이 계속 작동합니다. 외부 리소스 (애플리케이션 외부의 페이지 일 수도 있고 컨텐츠 전달 네트워크를 통해 제공하는 정적 컨텐츠 일 수도 있음)는 항상 절대 URL을 사용하도록 지시해야합니다. 다른 서버에 상주합니다.
//example.com/…, ?foobar및 #foobar도 상대 URL이며, (대한 확인을 잘 URL 경로로 시작하지 않는 ?foobar당신은 그것이 시작 않습니다 말할 수있는 빈 경로).
//example.com/…유형 URL은 상대적입니까? 그것은 나에게 새로운 것입니다.
http://site.ru/shop 폴더에 파일이있는 하위 사이트를 작성한다고 가정 하십시오 .
Link to home page
href="http://sites.ru/shop/"
Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"
Link from product page to home page
href="../../"상대 URL은 절대 URL보다 짧아 보이지만 사이트의 모든 페이지에서 링크를 변경하지 않고 사용할 수 있으므로 절대 URL이 더 바람직합니다.
우리는 "절대적으로"절대 URL과 "절대적으로"상대 URL이라는 두 가지 극단적 인 경우를 고려했습니다. 그러나이 세상의 모든 것은 상대적입니다. 이것은 URL에도 적용됩니다. 절대 URL에 대해 말할 때마다 항상 상대 URL을 지정해야합니다.
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"Google은 그러한 URL을 권장합니다. 그러나 이제는 일반적으로 http : //와 https : //가 서로 다른 사이트로 간주됩니다.
즉, 도메인의 루트 폴더를 기준으로합니다.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"모든 페이지가 동일한 도메인 내에 있으면 좋은 선택입니다. 사이트를 다른 도메인으로 이동할 때는 URL에서 도메인 이름을 대량으로 교체 할 필요가 없습니다.
<base> 태그는 기본 URL을 지정하며 모든 기본 링크와 앵커에 자동으로 추가됩니다. 기본 태그는 절대 링크에 영향을 미치지 않습니다. 기본 URL로 <base href = "http://sites.ru/shop/"> 홈페이지를 지정합니다.
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"이제 사이트를 도메인뿐만 아니라 하위 폴더로 이동할 수 있습니다. URL은 상대적으로 보이지만 실제로는 절대적임을 명심하십시오. 특히 앵커에주의하십시오. 현재 페이지 내에서 이동하려면 href = "# comments"가 아닌 href = "t-shirts / t-shirt-life-is-good / # comments"를 작성해야합니다. 후자는 홈페이지에 게재됩니다.
내부 링크의 경우 기본 상대 URL (5)을 사용합니다. 외부 링크 및 뉴스 레터에는 절대 URL (1)을 사용합니다.
명시 적으로 논의해야 할 세 가지 유형이 있습니다. 실제로 URL은 더 낮은 수준에서 처리되도록 추상화되었지만 개발자가 단일 URL을 직접 작성하지 않고도 평생 동안 사용할 수 있다고 말하고 싶습니다.
절대 URL은 코드를 프로토콜 및 도메인에 연결합니다. 이는 동적 URL로 극복 할 수 있습니다.
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>절대 장점 :
제어 -하위 도메인 및 프로토콜을 제어 할 수 있습니다. 불분명 한 하위 도메인을 통해 들어오는 사람들은 적절한 하위 도메인으로 유입됩니다. 보안과 비보안을 적절히 전환 할 수 있습니다.
구성 가능 -개발자는 절대적인 것을 좋아합니다. 절대 URL을 사용할 때 깔끔한 알고리즘을 디자인 할 수 있습니다. 단일 구성 파일에서 단일 변경으로 URL을 사이트 전체에서 업데이트 할 수 있도록 URL을 구성 할 수 있습니다.
Clairvoyance- 당신은 당신의 위치를 긁는 사람들을 검색하거나 추가 외부 링크를 선택할 수 있습니다.
루트 상대 URL은 코드를 기본 URL에 연결합니다. 이는 동적 URL 및 / 또는 기본 태그 로 극복 할 수 있습니다 .
<a href=“/index.php?q=”>.example.com/index.php?q=</a>루트 상대 프로 :
상대 URL은 코드를 디렉토리 구조에 연결합니다. 이것을 극복 할 방법이 없습니다. 상대 URL은 파일 시스템에서만 디렉토리를 통과하거나 멘탈 작업의 바로 가기로 유용합니다.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />상대 단점 :
혼란 -그 점은 몇 점입니까? 얼마나 많은 폴더입니까? 파일은 어디에 있습니까? 왜 작동하지 않습니까?
유지 관리 -파일이 실수로 이동하여 리소스로드가 중단 된 경우 링크가 사용자를 잘못된 페이지로 보내면 양식 데이터가 잘못된 페이지로 보내질 수 있습니다. 파일을 이동해야하는 경우로드를 종료 할 모든 자원과 올바르지 않은 모든 링크를 업데이트해야합니다.
스케일링 안 함 -웹 페이지가 복잡해지고 뷰가 여러 페이지에서 재사용되기 시작하면 상대 링크는 포함 된 파일을 기준으로합니다. 모든 페이지에있을 HTML의 탐색 스 니펫이있는 경우 상대는 많은 다른 장소와 관련이 있습니다. 사람들이 템플릿을 만들 때 가장 먼저 인식하는 것은 URL을 관리 할 방법이 필요하다는 것입니다.
컴퓨터 -그들은 당신의 브라우저에 의해 구현됩니다 (RFC에 따라). RFC3986의 5 장을 참조하십시오 .
웁스! -오류나 오타가 있으면 스파이더 트랩이 발생할 수 있습니다.
개발자들은 여기서 논의되는 의미에서 URL 작성을 중단했습니다. 모든 요청은 웹 사이트의 색인 파일에 대한 것이며 경로라는 쿼리 문자열을 포함합니다. 라우트는 애플리케이션에 생성 될 컨텐츠를 알려주는 미니 URL로 생각할 수 있습니다.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>노선 전문가 :
대부분의 사람들은 어떤 방식 으로든 프로젝트에서 세 가지 양식을 모두 사용합니다. 열쇠는 그것들을 이해하고 과제에 가장 적합한 것을 선택하는 것입니다.
웹 사이트에서 사용하는 경우 웹 사이트를 다른 도메인 이름으로 이동하거나 로컬로 디버깅 해야하는 경우 이와 같은 상대 URL을 사용하는 것이 좋습니다.
stackoverflow가 수행중인 작업을 살펴보십시오 (firefox의 Ctrl + U).
<a href="/users/recent/90691"> // Link to an internal element어떤 경우에는 절대 URL을 사용합니다.
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">...하지만 이것은 속도를 향상시키는 가장 좋은 방법입니다. 귀하의 경우, 당신이 그런 일을하는 것처럼 보이지 않으므로 걱정하지 않아도됩니다.
나는 여기에 대다수와 동의하지 않을 것입니다.
나는 프로젝트가 적은 개발자 (또는 자신 만)로 작을 때 상자 밖에서 생각하지 않고 빠르게 무언가를 시작하고 실행하려고 할 때 상대 URL 구성표가 "정확"하다고 생각합니다.
그러나 도메인과 프로토콜을 항상 전환하는 크고 기름진 시스템에서 작업을 시작하면 더 우아한 접근 방식이 필요합니다.
절대 URL과 상대 URL을 본질적으로 비교하면 절대가 우선합니다. 왜? 끊어지지 않기 때문입니다. 이제까지. 절대 URL은 정확히 그것이 말하는 것입니다. catch는 절대 URL을 유지해야 할 때입니다.
절대 URL 연결에 대한 약한 접근 방식은 실제로 전체 URL을 하드 코딩하는 것입니다. 좋은 생각이 아니며 아마도 사람들이 왜 그들을 유지하기 위해 위험하고 악하고 성가신 것으로 보는지에 대한 범인 일 것입니다. 더 좋은 방법은 사용하기 쉬운 URL 생성기를 작성하는 것입니다. 이것들은 작성하기 쉽고 믿을 수 없을만큼 강력합니다-프로토콜을 자동으로 감지하고 쉽게 구성 할 수 있습니다 (전체적으로 URL을 한 번 설정하면 전체 응용 프로그램에 대해 URL을 설정) 등 도메인을 자체적으로 주입합니다. 좋은 점 : 상대 URL을 사용하여 코딩을 계속하고 런타임에 응용 프로그램이 URL을 전체 절대 값으로 즉시 삽입합니다. 대박.
실제로 모든 현대 사이트가 일종의 동적 백엔드를 사용하는 방식을 고려할 때 해당 사이트가 그렇게하는 것이 가장 중요합니다. 절대 URL은 사용자가 가리키는 위치를 확실하게하는 것 이상으로 SEO 성능을 향상시킬 수 있습니다.
절대 URL이 어떻게 든 페이지의 로딩 시간을 변경한다는 주장은 신화라고 덧붙일 수 있습니다. 도메인의 무게가 몇 바이트 이상이고 1980 년대에 전화 접속 모뎀을 사용하고 있다면 반드시 확인하십시오. 그러나 그것은 더 이상 사실이 아닙니다. https://stackoverflow.com/ 은 25 바이트 인 반면 사이트의 탐색 영역에 사용하는 "topbar-sprite.png"파일의 무게는 9 + kb입니다. 즉, 추가 URL 데이터는 스프라이트 파일과 비교하여로드 된 데이터의 0.2 %이며 해당 파일은 큰 성능 저하로 간주되지 않습니다.
크고 최적화되지 않은 전체 페이지 배경 이미지는로드 시간이 훨씬 느려질 수 있습니다.
상대 URL을 사용해서는 안되는 흥미로운 게시물은 다음과 같습니다. http://yoast.com/relative-urls-issues/
예를 들어, 친척과 관련하여 발생할 수있는 문제는 때때로 서버 매핑 (크고 엉망인 프로젝트에 대해 알려줍니다)이 파일 이름과 일치하지 않으며 개발자가 그렇지 않은 상대 URL에 대해 가정 할 수 있다는 것입니다. 진실. 방금 오늘 내가 진행중인 프로젝트에서 그것을 보았고 전체 페이지가 다운되었습니다.
또는 개발자가 포인터를 전환하는 것을 잊었을 때 갑자기 Google이 전체 테스트 환경을 색인화했습니다. 으악-중복 콘텐츠 (SEO에 나쁜)!
절대는 위험 할 수 있지만 올바르게 사용하고 빌드 를 중단 할 수없는 방식으로 사용하면 더욱 신뢰할 수있는 것으로 입증됩니다. 위의 기사를 보면 Wordpress URL 생성기가 정말 멋진 이유가 많이 있습니다.
:)
/기본 경로에 연결하는 데 사용 합니까? 즉, /products/wallets/thing.html같은 반대 thing.html에 반대http://www.myshop.com/products/wallets/thing.html
echo Route::url('route_name')사이트 URL을 사용하여 절대 URL을 작성하고 HTTPS를 통한 옵션으로 정보를 라우팅하는 데 사용할 수있는 Kohana와 같은 경로를 좋아 합니다.
대부분의 경우 상대 URL을 사용하는 것이 좋습니다. 즉, 이식성이 뛰어납니다. 즉, 사이트를 들어 올려 즉시 작동 할 수있는 위치에 배치하여 디버깅 시간을 줄일 수 있습니다.
절대 URL과 상대 URL에 대한 꽤 괜찮은 기사가 있습니다.
URL 스키마 및 스키마의 특정 부분 (로 시작하는 URL http://, https://, ftp://등)의 절대적 URL이다.
다른 URL은 상대 URL이며, 달리 선언되지 않은 경우 참조가 사용되는 리소스의 URL 인 상대 URL을 확인하여 (따라서 의존하는) 기본 URL이 필요합니다.
살펴보세요 부록 C - RFC 2396 상대 URL를 해결 예를 들어.
www.yourserver.com 사이트가 있다고 가정 해 봅시다. 웹 문서의 루트 디렉토리에는 이미지 하위 디렉토리가 있고 myimage.jpg가 있습니다.
절대 URL은 문서의 정확한 위치를 정의합니다 (예 :
http://www.yourserver.com/images/myimage.jpg상대 URL은 예를 들어 이미지가있는 루트 웹 디렉토리에있는 경우 현재 디렉토리에 상대적인 위치를 정의합니다 .
images/myimage.jpg(그 루트 디렉토리에 상대적)
가능하면 항상 상대 URL을 사용해야합니다. 사이트를 www.anotherserver.com으로 이동하면 www.yourserver.com을 가리키는 모든 절대 URL을 업데이트해야합니다. 상대 URL은 그대로 작동합니다.
상대 URI 확인을 지원하는 모든 시스템에 대해 상대 URI와 절대 URI 모두 동일한 목표를 제공합니다. 참조. 그리고 그들은 상호 교환하여 사용할 수 있습니다. 따라서 각 경우마다 다르게 결정할 수 있습니다. 기술적으로 동일한 참조 를 제공합니다 .
정확하게 말하면, 각각의 상대 URI에는 이미 절대 URI가 있습니다. 그리고 그것은 상대 URI가 해결되는 기본 URI입니다. 따라서 상대 URI는 실제로 절대 URI 위에있는 기능입니다.
그렇기 때문에 상대 URI를 사용하면 절대 URI만으로 더 많은 것을 할 수 있습니다. 이는 절대 URI에 비해 유지 관리가 유연하지 않은 정적 웹 사이트에 특히 중요합니다.
상대적 URI 분석의 이러한 긍정적 인 효과는 동적 웹 애플리케이션 개발에도 활용 될 수 있습니다. 동적 환경에서 도입하는 비 유연성 절대 URI는 처리하기가 더 쉬우므로 URI 분석에 대해 확신이없는 일부 개발자 및 URI를 올바르게 구현하고 관리하는 방법 (항상 쉬운 것은 아님)이 종종 절대 사용을 선택하는 경우 융통성을 해결하기 위해 다른 동적 기능 (예 : URI 접두사를 포함하는 구성 변수)을 도입 할 수 있으므로 웹 사이트의 동적 부분에있는 URI
그렇다면 절대 URI를 사용하면 어떤 이점이 있습니까? 기술적으로는 없지만 내가 말하고자하는 것 : 상대 URI는 소위 절대 기본 URI에 대해 해결되어야하기 때문에 더 복잡합니다. 해결 방법은 수년 이후 엄격하게 정의되므로 URI 확인에 실수가있는 클라이언트를 실행할 수 있습니다. 절대 URI는 해결이 필요하지 않으므로 절대 URI를 사용하면 상대 URI 확인으로 잘못된 클라이언트 동작이 발생할 위험이 없습니다. 그렇다면 그 위험은 실제로 얼마나 높습니까? 글쎄, 그것은 매우 드 rare니다. 상대 URI 확인에 문제가있는 인터넷 브라우저 하나만 알고 있습니다. 그리고 그것은 일반적으로가 아니라 매우 모호한 경우에만있었습니다.
HTTP 클라이언트 (브라우저) 옆에는 하이퍼 텍스트 문서 나 코드 작성자도 더 복잡 할 수 있습니다. 여기서 절대 URI는 브라우저 주소 표시 줄에 그대로 입력 할 수 있으므로 테스트하기가 쉽다는 이점이 있습니다. 그러나 1 시간 작업이 아니라면 절대 및 상대 URI 처리를 실제로 이해하여 상대 링크의 이점을 실제로 활용할 수있는 것이 가장 유리합니다.