Nombre absolu d'URLs par rapport au nombre relatif D'URLs
je voudrais connaître les différences entre ces deux types D'URLs: les URLs relatives (pour les images, les fichiers CSS, les fichiers JS, etc.) et les Url absolues.
de plus, lequel est le mieux à utiliser?
12 réponses
en général, il est considéré comme la meilleure pratique d'utiliser des URLs relatives, de sorte que votre site web ne sera pas lié à L'URL de base de l'endroit où il est actuellement déployé. Par exemple, il pourra travailler sur localhost, ainsi que sur votre domaine public, sans modifications.
dois-je utiliser des URLs absolues ou relatives?
si par URL absolues vous voulez dire URLs incluant scheme (par exemple http / https) et le nom d'hôte (par exemple yourdomain.com) ne faites jamais cela (pour les ressources locales) parce qu'il sera terrible de maintenir et de déboguer.
disons que vous avez utilisé L'URL absolue partout dans votre code comme <img src="http://yourdomain.com/images/example.png"> . Maintenant ce qui se passera quand vous allez à:
- "1519360920 commutateur" un autre schéma (par exemple http - > https)
- commutateur de noms de domaine (test.yourdomain.com -> yourdomain.com)
dans le premier exemple, ce qui arrivera, c'est que vous recevrez des avertissements au sujet du contenu dangereux demandé sur la page. Parce que toutes vos URLs sont codées en dur pour utiliser http (: / /yourdomain.com/images/example.png). Et lors de l'exécution de vos pages sur http, le navigateur s'attend à ce que toutes les ressources soient chargées sur https pour éviter toute fuite de information.
dans le deuxième exemple, lorsque vous mettez votre site en direct à partir de l'environnement de test, cela signifierait que toutes les ressources pointent toujours vers votre domaine de test au lieu de votre domaine en direct.
ainsi pour répondre à votre question sur l'utilisation des URLs absolues ou relatives: utilisez toujours les URLs relatives (pour les ressources locales).
Quelle est la différence entre les différentes URLs?
voyons D'abord à ce que les URLs de différence sont nous pouvons utiliser:
-
http://yourdomain.com/images/example.png -
//yourdomain.com/images/example.png -
/images/example.png -
images/example.png
quelles ressources ces URL tentent-elles d'accéder sur le serveur?
dans les exemples ci-dessous, je suppose que le site web s'exécute à partir de l'emplacement suivant sur le serveur /var/www/mywebsite .
http://yourdomain.com/images/example.png
ci-dessus (dans l'absolu) URL tente d'accéder à la ressource /var/www/website/images/example.png . Ce type d'URL est quelque chose que vous toujours voulez éviter pour demander des ressources à partir de votre propre site web pour la raison décrite ci-dessus. Mais elle a sa place. Par exemple, si vous avez un site web http://yourdomain.com et vous souhaitez demander une ressource à partir d'un domaine externe sur http, vous devez utiliser cette. Par exemple: https://externalsite.com/path/to/image.png .
//yourdomain.com/images/example.png
cette URL est relative basée sur le schéma courant utilisé et devrait presque toujours être utilisée en incluant des ressources externes (images, javascripts, etc.).
ce que fait ce type D'URL est d'utiliser le schéma courant de la page sur laquelle elle se trouve. Cela signifie que vous êtes sur la page http://yourdomain.com et sur cette page est une balise d'image <img src="//yourdomain.com/images/example.png"> L'URL de l'image résoudrait en http://yourdomain.com/images/example.png .
Quand vous auriez été sur la page http**s**://yourdomain.com et sur cette page se trouve une balise image <img src="//yourdomain.com/images/example.png"> l'URL de l'image se résoudrait en https://yourdomain.com/images/example.png .
ceci empêche de charger des ressources sur https quand elles ne sont pas nécessaires et assure automatiquement que la ressource est demandée sur https quand elle est est nécessaire.
l'URL ci-dessus résout de la même manière du côté du serveur que le URL précédente:
ci-dessus (dans l'absolu) URL tente d'accéder à la ressource
/var/www/website/images/example.png.
/images/example.png
des ressources locales, c'est la manière préférée de référence. Il s'agit d'une URL relative basée sur le document root ( /var/www/mywebsite ) de votre site web. Cela signifie que lorsque vous avez <img src="/images/example.png"> il sera toujours décider de /var/www/mywebsite/images/example.png .
Si vous décidez de changer de domaine, il faudra encore travailler car elle est relative.
images/example.png
C'est aussi une URL relative, bien qu'un peu différente de la précédente. Cette URL est relative au chemin courant. Cela signifie qu'il se résoudra à des chemins différents selon l'endroit où vous êtes dans le site.
par exemple lorsque vous sont sur la page http://yourdomain.com et vous utilisez <img src="images/example.png"> il se résoudrait sur le serveur à /var/www/mywebsite/images/example.png comme prévu, cependant lorsque vous êtes sur la page http://yourdomain.com/some/path et vous utilisez la même étiquette d'image exacte, il se résoudra soudainement à /var/www/mywebsite/some/path/images/example.png .
Quand utiliser quoi?
lorsque vous demandez des ressources externes, vous voulez très probablement utiliser une URL relative au schéma (à moins que vous ne vouliez forcer un schéma différent) et lorsque vous traitez avec local ressources vous voulez utiliser des URLs relatives basées sur la racine du document.
un exemple de document:
<!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>
Certains (un peu) les doublons
voir ceci: 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
une url absolue inclut les parties avant la partie" chemin "- en d'autres termes, elle inclut le schéma (le http dans http://foo/bar/baz ) et le nom d'hôte (le foo dans http://foo/bar/baz ) (et éventuellement le port, userinfo et port).
les URL relatives commencent par un chemin.
les URL absolues sont, absolue: la localisation de la ressource peut être résolu en ne regardant que l'url elle-même. Une url relative est en un sens incomplète: pour la résoudre, vous avez besoin du schéma et du nom d'hôte, et ceux-ci sont généralement pris dans le contexte actuel. Par exemple, dans une page web à
http://myhost/mypath/myresource1.html
, vous pouvez mettre un lien comme
<a href="pages/page1">click me</a>
dans l'attribut href du lien, une url relative utilisée, et si elle est cliquée, elle doit être résolue afin de le suivre. Dans ce cas, le contexte actuel est
http://myhost/mypath/myresource1.html
ainsi le schéma, le nom d'hôte, et le chemin d'accès de ceux-ci sont pris et prépendés à pages/page1 , donnant
http://myhost/mypath/pages/page1
Si le lien aurait été:
<a href="/pages/page1">click me</a>
(notez le / figurant au début de l'url), il aurait été résolu
http://myhost/pages/page1
parce que le premier / indique la racine de l'hôte.
dans une application web, Je conseillerais d'utiliser des urls relatives pour toutes les ressources qui appartiennent à votre application. De cette façon, si vous changez l'emplacement des pages, tout continuera à fonctionner. Toutes les ressources externes (pouvant être des pages complètement en dehors de votre application, mais aussi du contenu statique que vous livrez via un réseau de diffusion de contenu) devraient toujours être pointées vers l'utilisation d'urls absolues: si vous ne le faites pas, il n'y a tout simplement aucun moyen de localiser parce qu'ils résident sur un autre serveur.
supposons que nous créons un sous-site dont les fichiers sont dans le dossier http://site.ru/shop .
1. Absolute URL
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/"
2. Relative URL
Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"
Link from product page to home page
href="../../"
bien que L'URL relative semble plus courte que l'URL absolue, mais les URL absolues sont plus préférables, puisqu'un lien peut être utilisé inchangé sur n'importe quelle page du site.
CAs intermédiaires
Nous avons considéré deux cas extrêmes: "absolument" absolue et "absolument"," Url relatives. Mais tout est relatif dans ce monde. Ceci s'applique également aux URLs. Chaque fois que vous dites à propos de l'URL absolue, vous devriez toujours spécifier par rapport à quoi.
3. Protocole-URL relative
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"
Google recommande une telle URL. Maintenant, cependant, il est généralement considéré que http:// et https:// sites différents.
4. Relatifs à la racine de l'URL
i. e. relatif au dossier racine du domaine.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
C'est un bon choix si toutes les pages sont dans le même domaine. Lorsque vous déplacez votre site vers un autre domaine, vous n'avez pas à effectuer un remplacement de masse du nom de domaine dans les URLs.
5. Base-relative URL (Page d'accueil-relative)
la balise
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"
Maintenant, vous pouvez déplacer votre site, non seulement à n'importe quel domaine, mais dans un sous-dossier. Il suffit de garder à l'esprit que, bien que les URLs ressemblent à relative, en fait, ils sont absolus. Faites particulièrement attention aux ancres. Pour naviguer dans la page actuelle, nous devons écrire href="t-shirts/t-shirt-vie-est-bonne/#comments" pas href = "# comments". Ce dernier lancera sur la page d'accueil.
Conclusion
pour les liens internes j'utilise les URLs de base relatives (5). Pour les liens externes et les bulletins d'information-je utiliser des Url absolues (1).
il y a vraiment trois types qui devraient être discutés explicitement. En pratique, bien que les URLs aient été abstraites pour être manipulées à un niveau inférieur et je dirais même que les développeurs pourraient passer toute leur vie sans écrire une seule URL à la main.
absolu
URLs absolues liez votre code au protocole et au domaine. Cela peut être surmonté avec des Url dynamiques.
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>
Les Avantages Absolus:
-
contrôle - le sous-domaine et le protocole peuvent être contrôlés. Les gens qui entrent par un sous-domaine obscur seront canalisés dans le sous-domaine approprié. Vous pouvez faire des allers-retours entre secure et non-secure comme il se doit.
-
Configurable - les développeurs aiment les choses à être absolu. Vous pouvez concevoir des algorithmes soigné en utilisant des URLs absolues. Les URLs peuvent être configurées de sorte qu'une URL puisse être mise à jour à l'échelle du site avec une seule modification dans un seul fichier de configuration.
-
Clairvoyance - vous pouvez rechercher les personnes qui grattent votre site ou peut-être ramasser quelques liens externes supplémentaires.
Relatif À La Racine Du
URLs relatives à la racine liez votre code à l'url de base. Cela peut être surmonté avec des URLs dynamiques et / ou balises de base .
<a href=“/index.php?q=”>.example.com/index.php?q=</a>
Pros Relatifs À La Racine:
- Configurable - la balise de base les rend relatives à n'importe quelle racine que vous choisissez, ce qui rend la commutation des domaines et la mise en œuvre des gabarits facile.
relatif 1519120920"
URLs relatives liez votre code à la structure du répertoire. Il n'y a aucun moyen de surmonter cela. Les URL relatives ne sont utiles que dans les systèmes de fichiers pour traverser des répertoires ou comme raccourci pour une tâche mineure.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />
Relative Contre:
-
confusion - combien de points est-ce? combien de dossiers? Où est le fichier? Pourquoi n'est-il pas de travail?
-
MAINTENANCE - si un fichier est accidentellement déplacé ressources arrêter de charger, liens envoyer l'utilisateur aux mauvaises pages, les données du formulaire peuvent être envoyés à la page incorrecte. Si un fichier doit être déplacé toutes les ressources qui vont quitter le chargement et tous les liens qui vont être incorrectes doivent être mis à jour.
-
DOES NOT SCALE - lorsque les pages web les liens relatifs seront relatifs au fichier dans lequel ils ont été inclus. Si vous avez un extrait de navigation de HTML qui va être sur chaque page alors relative sera relative à beaucoup d'endroits différents. La première chose que les gens réalisent quand ils commencent à créer un modèle est qu'ils ont besoin d'un moyen de gérer les URLs.
-
calculé - ils sont implémentés par votre navigateur (avec un peu de chance selon RFC). Voir Chapitre 5 dans RFC3986 .
-
OOPS! - les erreurs ou fautes de frappe peuvent entraîner des pièges à araignées.
L'évolution des itinéraires
les développeurs ont cessé d'écrire des URLs dans le sens dont il est question ici. Toutes les demandes sont pour un fichier index du site web et contiennent une chaîne de requête, aka un itinéraire. La route peut être considérée comme une mini URL qui indique à votre application le contenu à générer.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>
Itinéraires Pour:
- tous les avantages des urls absolues.
- utilisation de n'importe quel caractère dans L'URL.
- plus de Contrôle (bon pour le référencement).
- possibilité de générer des URLs algorithmiquement. Cela permet l'Url pour être configurable. Modifier L'URL est un simple changement dans un seul fichier.
- Pas besoin de 404 pas fonde. Les routes de repli peuvent afficher une carte du site ou une page d'erreur.
- Pratique de la sécurité d'accès indirect aux fichiers de l'application. Les gardes peuvent s'assurer que tout le monde arrive par la bonne voie.
- Practicalality in MVC approach.
mon Prendre
la plupart des gens utiliseront les trois formes dans leurs projets d'une manière ou d'une autre. La clé est de comprendre et de choisir celui le mieux adapté à la tâche.
si c'est pour une utilisation dans votre site web, il est préférable d'utiliser L'URL relative, comme ceci si vous avez besoin de déplacer le site web à un autre nom de domaine ou tout simplement déboguer localement, vous pouvez.
regardez ce que fait stackoverflow (ctrl+U in firefox):
<a href="/users/recent/90691"> // Link to an internal element
dans certains cas, ils utilisent des urls absolues:
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">
... mais ce n'est qu'une pratique exemplaire pour améliorer la vitesse. Dans votre cas, il n'a pas l'air comme si tu faisais quelque chose comme ça pour que je ne m'inquiète pas.
je vais devoir être en désaccord avec la majorité ici.
je pense que le schéma D'URL relatif est" bien " quand vous voulez obtenir rapidement quelque chose et de fonctionner et ne pas penser en dehors de la boîte, en particulier si votre projet est petit avec peu de développeurs (ou juste vous-même).
cependant, une fois que vous commencez à travailler sur de grands systèmes gras où vous changez les domaines et les protocoles tout le temps, je crois qu'une approche plus élégante est en ordre.
lorsque vous comparez des URLs absolues et relatives dans l'essence, Absolute gagne. Pourquoi? Parce qu'il ne brisera jamais. Jamais. Une URL absolue est exactement ce qu'elle dit qu'elle est. Le hic est quand vous devez maintenir vos URLs absolues.
l'approche faible à la liaison D'URL absolue est en fait le codage dur de L'URL entière. Pas une bonne idée, et probablement le coupable de pourquoi les gens les voient comme dangereux/mal/ennuyeux à maintenir. Une meilleure approche est d'écrire vous-même un facile à utilisez le générateur D'URL. Ceux - ci sont faciles à écrire, et peuvent être incroyablement puissant-détection automatique de votre protocole, facile à configurer (littéralement définir l'url une fois pour l'ensemble de l'application), etc, et il injecte votre domaine tout seul. La bonne chose à ce sujet: vous continuez à coder en utilisant des URLs relatives, et au moment de l'exécution l'application insère vos URLs en tant qu'absolues complètes à la volée. Impressionnant.
vu que pratiquement tous les sites modernes utilisent une sorte de dynamique back-end, c'est dans le meilleur intérêt du site pour le faire de cette façon. Les URLs absolues font plus que simplement vous rendre certain de l'endroit où elles pointent vers - elles peuvent aussi améliorer les performances de SEO.
je pourrais ajouter que l'argument que les URLs absolues est en quelque sorte va changer le temps de charge de la page est un mythe. Si votre domaine pèse plus de quelques octets et que vous êtes sur un modem commuté dans les années 1980, bien sûr. Mais ce n'est pas le cas aujourd'hui. https://stackoverflow.com / est de 25 octets, alors que le" topbar-sprite.png" fichier qu'ils utilisent pour la nav du site pèse 9+ kb. Cela signifie que les données URL supplémentaires est .2% des données chargées par rapport au fichier sprite, et ce fichier n'est même pas considéré comme un grand succès.
cette grande image pleine page, non optimisée, est beaucoup plus susceptible de ralentir vos temps de chargement.
un billet intéressant sur pourquoi les URL relatives ne doivent pas être utilisées est ici: http://yoast.com/relative-urls-issues /
un problème qui peut se poser avec les parents, par exemple, est que parfois les mappages de serveur (faites attention sur les grands projets foirés) ne s'alignent pas avec les noms de fichiers et le développeur peut faire une supposition au sujet d'une URL relative qui n'est tout simplement pas vrai. J'ai vu ça aujourd'hui sur un projet que je suis en train de réaliser et ça a fait toute une page.
ou peut-être un développeur a oublié de changer un pointeur et tout d'un coup google indexé votre environnement de test entier. Whoops-contenu dupliqué (mauvais pour le référencement!).
absolues peuvent être dangereux, mais lorsqu'ils sont utilisés correctement et d'une manière que ne peut pas briser votre construction ils sont prouvés pour être plus fiable. Regardez l'article ci-dessus qui donne un tas de raisons pour lesquelles le générateur D'url Wordpress est super génial.
:)
dans la plupart des cas les URLs relatives sont le chemin à suivre, elles sont portables par nature, ce qui signifie que si vous voulez soulever votre site et le mettre quelqu'un où d'autre il fonctionnerait instantanément, réduisant éventuellement les heures de débogage.
Il y a un assez décent article sur l'absolue vs Url relatives , check it out.
une URL qui commence par la partie spécifique au scheme et au scheme ( http:// , https:// , ftp:// , etc.) est une URL absolue.
toute autre URL est une URL relative et nécessite une URL de base.L'URL relative est résolue (et dépend donc de) qui est L'URL de la ressource dans laquelle la référence est utilisée si elle n'est pas déclarée autrement.
jetez un coup d'oeil à RFC 2396 – Annexe C pour des exemples de résolution D'URLs relatives.
disons que vous avez un site www.yourserver.com. Dans le répertoire racine pour les documents web vous avez une sous-directoy d'images et dans cela vous avez myimage.jpg.
une URL absolue définit l'emplacement exact du document, par exemple:
http://www.yourserver.com/images/myimage.jpg
une URL relative définit l'emplacement par rapport au répertoire courant , par exemple, étant donné que vous êtes dans le répertoire Web racine votre image est dans:
images/myimage.jpg
(relatif à ce répertoire racine)
vous devez toujours utiliser des URLS relatives si possible. Si vous déplacez le site vers www.anotherserver.com vous devez mettre à jour toutes les URLs absolues qui pointent vers www.yourserver.com ceux qui sont relatifs continueront de fonctionner comme tels.
pour chaque système qui supporte la résolution relative des URI, les URI relatifs et absolus servent le même objectif: le référencement. Et ils peuvent être utilisés de façon interchangeable. Donc vous pourriez décider dans chaque cas différent. Techniquement, ils fournissent le même référencement.
pour être précis, avec chaque URI relatif il y a déjà un URI absolu. Et c'est L'URI de base contre lequel L'URI relatif est résolu. Si un parent URI est en fait une caractéristique sur le dessus de L'URIs absolu.
et c'est aussi pourquoi avec L'URIs relatif Vous pouvez faire plus comme avec un URI absolu seul - c'est particulièrement important pour les sites statiques qui autrement ne pourrait pas être aussi flexible à maintenir que par rapport à L'URIs absolu.
ces effets positifs de la résolution relative de L'URI peuvent également être exploités pour le développement dynamique d'applications web. L'inflexibilité absolue do introduire sont également plus faciles à gérer, dans un environnement dynamique, donc pour certains développeurs qui ne sont pas certains de la résolution de L'URI et de la façon de le mettre en œuvre et de le gérer correctement (pas que ce soit toujours facile), optent souvent pour l'utilisation de L'URIs absolu dans une partie dynamique d'un site web car ils peuvent introduire d'autres fonctionnalités dynamiques (par exemple, la variable de configuration contenant le préfixe URI) afin de travailler autour de l'inflexibilité.
alors quel est l'avantage d'utiliser un URIs absolu? Techniquement, il n'y en a pas, mais je dirais que les URI relatifs sont plus complexes parce qu'ils doivent être résolus contre ce qu'on appelle L'URI de base absolue. Même la résolution est strictement défini depuis des années, vous pourriez courir sur un client qui a une erreur dans la résolution D'URI. Comme les URI absolus n'ont pas besoin de résolution, l'utilisation des URI absolus ne présente aucun risque de comportement anormal du client avec une résolution relative des URI. Alors, quelle est la hauteur réelle du risque? Eh bien, c'est très rare. Je ne connais Qu'un seul Internet navigateur qui avait un problème avec la résolution relative de L'URI. Et ce n'était pas en général, mais seulement dans un cas très (obscur).
à côté du client HTTP (navigateur) c'est peut-être plus complexe pour un auteur de documents ou de code hypertexte aussi bien. Ici, l'URI absolu a l'avantage qu'il est plus facile de tester, il vous suffit d'entrer comme ça dans la barre d'adresse de votre navigateur. Cependant, si ce n'est pas seulement votre travail d'une heure, il est le plus souvent plus utile pour vous de comprendre la manipulation D'URI absolue et relative de sorte que vous pouvez réellement exploiter les avantages de la liaison relative.
je recommande vivement des URLs relatives pour pointer des bits du même site vers d'autres bits du même site.
n'oubliez pas qu'un changement à HTTPS - même si dans le même site - va avoir besoin d'une URL absolue.