Les gens parlent des URL , des URI et des URN comme s'il s'agissait de choses différentes, mais ils se ressemblent à l'œil nu.
Quelles sont les différences distinctes entre eux?
( URIs ( URLs ) )
Les gens parlent des URL , des URI et des URN comme s'il s'agissait de choses différentes, mais ils se ressemblent à l'œil nu.
Quelles sont les différences distinctes entre eux?
( URIs ( URLs ) )
Réponses:
De RFC 3986 :
Un URI peut être classé comme localisateur, nom ou les deux. Le terme "Uniform Resource Locator" (URL) fait référence au sous-ensemble d'URI qui, en plus d'identifier une ressource, fournissent un moyen de localiser la ressource en décrivant son mécanisme d'accès principal (par exemple, son "emplacement" réseau). Le terme "nom de ressource uniforme" (URN) a été utilisé historiquement pour désigner les deux URI sous le schéma "urn" [RFC2141] , qui doivent rester globalement uniques et persistants même lorsque la ressource cesse d'exister ou devient indisponible, et à tout autre URI avec les propriétés d'un nom.
Donc, toutes les URL sont des URI (en fait pas tout à fait - voir ci-dessous), et tous les URN sont des URI - mais les URN et les URL sont différents, vous ne pouvez donc pas dire que tous les URI sont des URL.
EDIT: j'avais déjà pensé que toutes les URL sont des URI valides, mais selon les commentaires:
Pas "toutes les URL sont des URI". Cela dépend de l'interprétation de la RFC. Par exemple, en Java, l'analyseur URI n'aime pas
[
ou]
et c'est parce que la spécification dit "ne devrait pas" et non "ne doit pas".
Ce qui trouble encore plus les eaux, malheureusement.
Si vous n'avez pas encore lu la réponse de Roger Pate , je vous conseillerais de le faire également.
[
ou ]
et c'est parce que la spécification dit "ne devrait pas" et non "ne doit pas".
java.net.URI
document lui-même dit "chaque URL est un URI, de manière abstraite, mais pas chaque URI est une URL". Et java.net.URL
fait des trucs bizarres comme vérifier l'égalité des URL en résolvant les noms d'hôte en adresses IP (ce qui semble en contradiction avec RFC 3986 sec 6 en premier lieu, et casse w les hôtes virtuels). Je pense que cela signifie simplement que la bibliothèque standard Java a un comportement de classe incohérent.
Les URI identifient et les URL localisent ; cependant, les localisateurs sont également des identifiants , donc chaque URL est également un URI, mais il existe des URI qui ne sont pas des URL.
Ceci est mon nom, qui est un identifiant. C'est comme un URI, mais ne peut pas être une URL, car il ne vous dit rien sur ma position ou comment me contacter. Dans ce cas, il arrive également d'identifier au moins 5 autres personnes aux États-Unis seulement.
Il s'agit d'un localisateur, qui est un identifiant pour cet emplacement physique. C'est comme une URL et un URI (puisque toutes les URL sont des URI), et m'identifie aussi indirectement comme "résident de ..". Dans ce cas, cela m'identifie de manière unique, mais cela changerait si j'obtenais un colocataire.
Je dis "j'aime" car ces exemples ne suivent pas la syntaxe requise.
De Wikipédia :
En informatique, un URL (Uniform Resource Locator) est un sous-ensemble de l'URI (Uniform Resource Identifier) qui spécifie où une ressource identifiée est disponible et le mécanisme pour la récupérer. Dans l'usage courant et dans de nombreux documents techniques et discussions verbales, il est souvent utilisé à tort comme synonyme d'URI , ... [c'est moi qui souligne]
En raison de cette confusion courante, de nombreux produits et documents utilisent de manière incorrecte un terme au lieu de l'autre, attribuent leur propre distinction ou les utilisent de manière synonyme.
Mon nom, Roger Pate, pourrait ressembler à un URN (Uniform Resource Name), sauf que ceux-ci sont beaucoup plus réglementés et destinés à être uniques à la fois dans l' espace et dans le temps.
Parce que je partage actuellement ce nom avec d'autres personnes, il n'est pas unique au monde et ne conviendrait pas comme URN. Cependant, même si aucune autre famille n'a utilisé ce nom, je porte le nom de mon grand-père paternel, il ne serait donc pas unique au fil du temps. Et même si ce n'était pas le cas, la possibilité de nommer mes descendants après moi rend cela inadapté comme URN.
Les URN sont différents des URL dans cette contrainte d'unicité rigide, même s'ils partagent tous deux la syntaxe des URI.
URNs are different from URLs in this rigid uniqueness constraint
Cela signifie-t-il que les URL n'identifient pas de manière unique un emplacement?
Les URI sont une norme pour identifier les documents à l'aide d'une courte chaîne de chiffres, de lettres et de symboles. Ils sont définis par la RFC 3986 - Uniform Resource Identifier (URI): syntaxe générique . Les URL, URN et URC sont tous des types d'URI.
Contient des informations sur la façon d'extraire une ressource de son emplacement. Par exemple:
http://example.com/mypage.html
ftp://example.com/download.zip
mailto:user@example.com
file:///home/user/file.txt
tel:1-888-555-5555
http://example.com/resource?foo=bar#fragment
/other/link.html
(Une URL relative, utile uniquement dans le contexte d'une autre URL)Les URL commencent toujours par un protocole ( http
) et contiennent généralement des informations telles que le nom d'hôte réseau ( example.com
) et souvent un chemin de document ( /foo/mypage.html
). Les URL peuvent avoir des paramètres de requête et des identificateurs de fragment.
Identifie une ressource par un nom unique et persistant, mais ne vous indique pas nécessairement comment la localiser sur Internet. Il commence généralement par le préfixe urn:
Par exemple:
urn:isbn:0451450523
pour identifier un livre par son numéro ISBN.urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
un identifiant globalement uniqueurn:publishing:book
- Un espace de noms XML qui identifie le document comme un type de livre.Les URN peuvent identifier des idées et des concepts. Ils ne se limitent pas à l'identification de documents. Lorsqu'un URN représente un document, il peut être traduit en URL par un "résolveur". Le document peut ensuite être téléchargé à partir de l'URL.
Pointe vers les métadonnées d'un document plutôt que vers le document lui-même. Un exemple d'URC est celui qui pointe vers le code source HTML d'une page comme:view-source:http://example.com/
Plutôt que de les localiser sur Internet ou de les nommer, les données peuvent être placées directement dans un URI. Un exemple serait data:,Hello%20World
.
La spécification W3 pour HTML indique que la href
balise d'ancrage peut contenir un URI, pas seulement une URL. Vous devriez pouvoir mettre un URN tel que <a href="urn:isbn:0451450523">
. Votre navigateur résoudrait alors cet URN en URL et téléchargerait le livre pour vous.
Pas que je sache, mais un navigateur Web moderne implémente le schéma d'URI de données.
Non. Les URL relatives et absolues sont des URL (et des URI).
Non. Les deux URL avec et sans paramètres de requête sont des URL (et des URI).
Non. Les deux URL avec et sans identificateurs de fragment sont des URL (et des URI).
Non. Les URL sont définies comme un sous-ensemble strict d'URI. Si un analyseur autorise un caractère dans une URL mais pas dans un URI, il y a un bogue dans l'analyseur. Les spécifications détaillent en détail quels caractères sont autorisés dans quelles parties des URL et des URI. Certains caractères peuvent être autorisés uniquement dans certaines parties de l'URL, mais les caractères seuls ne font pas la différence entre les URL et les URI.
Oui. Le W3C a réalisé qu'il y avait une tonne de confusion à ce sujet. Ils ont publié un document de clarification d'URI qui dit qu'il est maintenant OK d'utiliser les termes URL et URI de manière interchangeable (pour signifier URI). Il n'est plus utile de segmenter strictement les URI en différents types tels que URL, URN et URC.
La définition de l'URN est maintenant plus lâche que ce que j'ai indiqué ci-dessus. Le dernier RFC sur les URI indique que tout URI peut désormais être un URN (qu'il commence ou non urn:
) tant qu'il a «les propriétés d'un nom». C'est-à-dire: il est globalement unique et persistant même lorsque la ressource cesse d'exister ou devient indisponible. Un exemple: les URI utilisés dans les doctypes HTML tels que http://www.w3.org/TR/html4/strict.dtd
. Cet URI continuerait à nommer le doctype transitionnel HTML4 même si la page du site Web w3.org était supprimée.
file://
préfixe. Bien que les navigateurs gèrent généralement les chemins de fichiers non formatés URL. Mozilla publie leurs cas de test pour les URL de fichiers .
mailto:user@example.com
comme URL mais une autre réponse ci-dessous dit que c'est un URN? Quelle est la bonne? Est-ce à la fois URN et URL?
En résumé: un URI identifie, une URL identifie et localise.
Considérez une édition spécifique de la pièce de Shakespeare Roméo et Juliette , dont vous avez une copie numérique sur votre réseau domestique.
Vous pouvez identifier le texte comme urn:isbn:0-486-27557-4
.
Ce serait un URI, mais plus spécifiquement un URN * car il nomme le texte .
Vous pouvez également identifier le texte comme file://hostname/sharename/RomeoAndJuliet.pdf
.
Ce serait également un URI, mais plus spécifiquement une URL car il localise le texte .
* Nom de ressource uniforme
(Notez que mon exemple est adapté de Wikipedia )
ISBN 0486275574
le texte est également nommé et peut donc être qualifié d'URN. Je choisis un format que je croyais plus familier aux lecteurs.
Ce sont des réponses très bien écrites mais de longue haleine. Voici la différence en ce qui concerne CodeIgniter :
URL - http://example.com/some/page.html
URI - /some/page.html
En termes simples, l'URL est le moyen complet d'identifier n'importe quelle ressource n'importe où et peut avoir différents protocoles comme FTP, HTTP, SCP, etc.
L'URI est une ressource sur le domaine actuel, il a donc besoin de moins d'informations pour être trouvé.
Dans chaque cas où CodeIgniter utilise le mot URL ou URI, c'est la différence dont ils parlent, bien que dans le grand schéma du Web, il ne soit pas correct à 100%.
/some/page.html
n'est pas un URI. Il s'agit d'une "référence relative", qui est une sorte de "référence URI". Combiné avec un contexte d'URI de base, il peut être résolu en URI, mais n'est pas lui-même un URI. Voir la section 4.1 de la RFC 3986 . CodeIgniter utilise probablement mal les termes et cela devrait être rappelé; le Q (tel qu'il est actuellement modifié) n'est pas encadré comme spécifique à CodeIgniter.
Tout d'abord, sortez votre esprit de la confusion et prenez les choses simplement et vous comprendrez.
URI => Uniform Resource Identifier Identifie une adresse complète de la ressource, à savoir l'emplacement, le nom ou les deux.
URL => Uniform Resource Locator Identifie l'emplacement de la ressource.
URN => Uniform Resource Name Identifie le nom de la ressource
Exemple
Nous avons l'adresse https://www.google.com/folder/page.html où,
URI (Uniform Resource Identifier) => https://www.google.com/folder/page.html
URL (Uniform Resource Locator) => https://www.google.com/
URN (Uniform Resource Name) => /folder/page.html
URI => (URL + URN) ou URL uniquement ou URN uniquement
Un petit ajout aux réponses déjà publiées, voici un diagramme de Venn pour résumer la théorie (de la belle explication de Prateek Joshi ):
Et un exemple (également sur le site Web de Prateek):
#posts
identifiant du fragment pourrait faire partie de l'URL
C'est l'un des sujets les plus déroutants et peut-être non pertinents que j'ai rencontrés en tant que professionnel du Web.
Si je comprends bien, un URI est une description de quelque chose, suivant un format accepté, qui peut définir à la fois ou soit le nom unique (identification) de quelque chose et son emplacement.
Il existe deux sous-ensembles de base - les URL, qui définissent l'emplacement (en particulier pour un navigateur essayant de rechercher une page Web) et les URN, qui définissent le nom unique de quelque chose.
J'ai tendance à penser que les URN sont similaires aux GUID. Ils sont simplement une méthodologie standardisée pour fournir des noms uniques pour les choses. Comme dans le déclaratif d'espace de noms qui utilise le nom d'une entreprise - ce n'est pas comme s'il y avait une ressource sur un serveur quelque part pour correspondre à cette ligne de texte - il identifie simplement quelque chose de manière unique.
J'ai également tendance à éviter complètement le terme URI et à discuter des choses uniquement en termes d'URL ou d'URN, le cas échéant, car cela crée beaucoup de confusion. La question à laquelle nous devrions vraiment essayer de répondre pour les gens n'est pas tant la sémantique, mais comment identifier lors de la rencontre des termes s'il existe ou non une différence pratique qui changera l'approche d'une situation de programmation. Par exemple, si quelqu'un me corrige dans une conversation et dit: «oh, ce n'est pas une URL, c'est un URI», je sais qu'il en est plein. Si quelqu'un dit "nous utilisons un URN pour définir la ressource", je suis plus susceptible de comprendre que nous ne le nommons que de manière unique, pas le localiser sur un serveur.
Si je suis loin de la base - faites le moi savoir!
redirect_url
place de redirect_uri
, est-ce que quelqu'un s'en soucierait vraiment?
Identité = nom avec emplacement
Chaque URL ( U niform R esource L ocator) est un URI ( U niform R esource I dentifier), de manière abstraite, mais chaque URI n'est pas une URL. Il existe une autre sous-catégorie d'URI: URN ( U niform R esource N ame), qui est une ressource nommée mais ne spécifie pas comment les localiser, comme mailto, news, ISBN is URIs. La source
URNE:
urn:[namespace identifier]:[namespace specific string]
arn:partition:service:region:account-id:resource
URL:
[scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
Analogie:
Pour joindre une personne: Conduite (protocole autres SMS, email, téléphone), Adresse (nom d'hôte autre numéro de téléphone, emailid) et nom de la personne (nom de l'objet avec un chemin relatif).
URI => http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
Les URL sont un sous-ensemble d'URI (qui contiennent également des URN).
Fondamentalement, un URI est un identificateur général, où une URL spécifie un emplacement et un URN spécifie un nom.
[
et ]
pas un URI.
Un autre exemple que j'aime utiliser lorsque je pense aux URI est l'attribut xmlns d'un document XML:
<rootElement xmlns:myPrefix="com.mycompany.mynode">
<myPrefix:aNode>some text</myPrefix:aNode>
</rootElement>
Dans ce cas, com.mycompany.mynode serait un URI qui identifie de manière unique l'espace de noms "myPrefix" pour tous les éléments qui l'utilisent dans mon document XML. Ce n'est PAS une URL car elle n'est utilisée que pour identifier, pas pour localiser quelque chose en soi.
En raison de difficultés à distinguer clairement l'URI et l'URL, pour autant que je m'en souvienne, le W3C ne fait plus de différence entre l'URI et l'URL ( http://www.w3.org/Addressing/ ).
C'est la même chose . Un URI est une généralisation d'une URL. À l'origine, les URI devaient être divisés en URL (adresses) et URN (noms), mais il y avait peu de différence entre une URL et un URI et les URI http étaient utilisés comme espaces de noms même s'ils ne localisaient en fait aucune ressource.
URI, URL, URN
Comme l'indique l'image ci-dessus, il y a trois composants distincts en jeu ici. Il est généralement préférable d'aller à la source lorsque vous discutez de sujets comme ceux-ci, alors voici un extrait de Tim Berners-Lee, et. Al. dans RFC 3986: Uniform Resource Identifier (URI): Syntaxe générique:
Un identificateur de ressource uniforme (URI) est une séquence compacte de caractères qui identifie une ressource abstraite ou physique.
Un URI peut être classé comme localisateur, nom ou les deux. Le terme «Uniform Resource Locator» (URL) fait référence au sous-ensemble d'URI qui, en plus d'identifier une ressource, fournissent un moyen de localiser la ressource en décrivant son mécanisme d'accès principal (par exemple, son «emplacement» de réseau).
L'URI est une sorte de super classe d'URL et d'URN. Wikipedia a un bel article à leur sujet avec des liens vers le bon ensemble de RFC.
Wikipédia vous fournira toutes les informations dont vous avez besoin ici. Citant de http://en.wikipedia.org/wiki/URI :
Une URL est un URI qui, en plus d'identifier une ressource, fournit des moyens d'agir sur ou d'obtenir une représentation de la ressource en décrivant son mécanisme d'accès principal ou son "emplacement" de réseau.
URL
Une URL est une spécialisation d'URI qui définit l'emplacement réseau d'une ressource spécifique. Contrairement à un URN, l'URL définit comment la ressource peut être obtenue. Nous utilisons des URL tous les jours sous la forme de http://example.com
etc. Mais une URL ne doit pas nécessairement être une URL HTTP, elle peut l'être ftp://example.com
aussi, etc.
URI
Un URI identifie une ressource soit par emplacement, soit par nom, soit par les deux. Plus souvent qu'autrement, la plupart d'entre nous utilisent des URI qui définissent un emplacement pour une ressource. Le fait qu'un URI puisse identifier une ressource à la fois par son nom et son emplacement a conduit à beaucoup de confusion à mon avis. Un URI a deux spécialisations appelées URL et URN.
Différence entre URL et URI
Un URI est un identifiant pour une ressource, mais une URL vous donne des informations spécifiques pour obtenir cette ressource. Un URI est une URL et comme l'a souligné un commentateur, il est désormais considéré comme incorrect d'utiliser l'URL lors de la description des applications. Généralement, si l'URL décrit à la fois l'emplacement et le nom d'une ressource, le terme à utiliser est URI. Comme c'est généralement le cas que la plupart d'entre nous rencontrons tous les jours, URI est le terme correct.
Conformément à la RFC 3986 , les URI sont composés des éléments suivants:
scheme://authority/path?query
L'URI décrit le protocole d'accès à une ressource ( chemin ) ou à une application ( requête ) sur un serveur ( autorité ).
Toutes les URL sont des URI et tous les URN sont des URI, mais tous les URI ne sont pas des URL.
Veuillez vous référer pour plus de détails:
Un URI identifie une ressource soit par emplacement, soit par nom, soit par les deux. Plus souvent qu'autrement, la plupart d'entre nous utilisent des URI qui définissent un emplacement pour une ressource. Le fait qu'un URI puisse identifier une ressource à la fois par son nom et son emplacement a conduit à beaucoup de confusion à mon avis. Un URI a deux spécialisations appelées URL et URN.
Une URL est une spécialisation d'URI qui définit l'emplacement réseau d'une ressource spécifique. Contrairement à un URN, l'URL définit comment la ressource peut être obtenue. Nous utilisons des URL tous les jours sous la forme de http://stackoverflow.com , etc. Mais une URL ne doit pas nécessairement être une URL HTTP, elle peut l'être ftp://example.com
, etc.
Bien que les termes URI et URL soient strictement définis, beaucoup utilisent les termes à d'autres fins que celles pour lesquelles ils sont définis.
Prenons l'exemple d'Apache. Si http://example.com/foo est demandé à partir d'un serveur Apache, les variables d'environnement suivantes seront définies:
REDIRECT_URL
: /foo
REQUEST_URI
: /foo
Avec mod_rewrite activé, vous aurez également ces variables:
REDIRECT_SCRIPT_URL
: /foo
REDIRECT_SCRIPT_URI
: http://example.com/foo
SCRIPT_URL
: /foo
SCRIPT_URI
: http://example.com/foo
Cela pourrait être la raison d'une certaine confusion.
Voir ce document . Plus précisément,
une URL est un type d'URI qui identifie une ressource via une représentation de son mécanisme d'accès principal (par exemple, son "emplacement" réseau), plutôt que par d'autres attributs qu'elle peut avoir.
Ce n'est pas un terme extrêmement clair, vraiment.
Après avoir lu les articles, je trouve des commentaires très pertinents. En bref, la confusion entre les définitions d'URL et d'URI est basée en partie sur la définition qui dépend et sur l'utilisation informelle du mot URI dans le développement de logiciels.
Par définition, l'URL est un sous-ensemble de l'URI [RFC2396]. L'URI contient l'URN et l'URL. L'URI et l'URL ont chacun leur propre syntaxe spécifique qui leur confère le statut d'URI ou d'URL. L'URN sert à identifier de manière unique une ressource tandis que l'URL sert à localiser une ressource. Notez qu'une ressource peut avoir plusieurs URL mais un seul URN. [RFC2611]
En tant que développeurs et programmeurs Web, nous nous occuperons presque toujours de l'URL et donc de l'URI. Maintenant, une URL est spécifiquement définie pour avoir tout le schéma de pièces: partie spécifique au schéma, comme par exemple https://stackoverflow.com/questions . Il s'agit d'une URL et c'est également un URI. Considérons maintenant un lien relatif incorporé dans la page tel que ../index.html. Ce n'est plus une URL par définition. C'est toujours ce que l'on appelle une "référence URI" [RFC2396].
Je crois que lorsque le mot URI est utilisé pour désigner des chemins relatifs, "URI-référence" est en fait ce à quoi on pense. De manière informelle, les systèmes logiciels utilisent l'URI pour faire référence au cheminement relatif et à l'URL de l'adresse absolue. Donc dans ce sens, un chemin relatif n'est plus une URL mais toujours une URI.
Voici ma simplification:
URN: nom de ressource unique, c'est-à-dire "quoi" (par exemple urn: issn: 1234-5678). Ceci est censé être unique .. car dans deux documents différents ne peuvent pas avoir la même urne. Un peu comme "uuid"
URL: "où" pour le trouver (par exemple https://google.com/pub?issnid=1234-5678 .. ou ftp://somesite.com/doc8.pdf )
URI: peut être un URN ou une URL. Cette définition floue est due au RFC 3986 produit par le W3C et l'IETF.
La définition de l'URI a changé au fil des ans, il est donc logique que la plupart des gens soient confus. Cependant, vous pouvez maintenant vous consoler dans le fait que vous pouvez faire référence à http://somesite.com/something comme une URL ou un URI ... et vous aurez raison de toute façon (au moins pour le moment de toute façon .. .)
Je me demandais la même chose et j'ai trouvé ceci: http://docs.kohanaphp.com/helpers/url .
Vous pouvez voir un exemple clair en utilisant la url::current()
méthode. Si vous avez cette URL : http://example.com/kohana/index.php/welcome/home.html?query=string
alors en utilisant url:current()
vous donne l' URI qui, selon la documentation, est: bienvenue / accueil
Les URI sont nés de la nécessité d'identifier les ressources sur le Web et d'autres ressources Internet telles que les boîtes aux lettres électroniques de manière uniforme et cohérente. Ainsi, on peut introduire un nouveau type de widget: les URI pour identifier les ressources du widget ou utiliser les tel: URI pour avoir des liens Web provoquant des appels téléphoniques lors de l'appel.
Certains URI fournissent des informations pour localiser une ressource (comme un nom d'hôte DNS et un chemin sur cette machine), tandis que d'autres sont utilisés comme noms de ressource purs. L' URL est réservée aux identificateurs qui sont des localisateurs de ressources , y compris les URL 'http' telles que http://stackoverflow.com , qui identifie la page Web au chemin donné sur l'hôte. Un autre exemple est l'URL «mailto», comme mailto: fred@mail.org , qui identifie la boîte aux lettres à l'adresse donnée.
Les URN sont des URI qui sont utilisés comme noms de ressource purs plutôt que comme localisateurs. Par exemple, l'URI: mid: 0E4FC272-5C02-11D9-B115-000A95B55BC8@stackoverflow.com est un URN qui identifie l'e-mail qui le contient dans son champ 'Message-Id'. L'URI sert à distinguer ce message de tout autre message électronique. Mais il ne fournit lui-même l'adresse du message dans aucun magasin.
Afin de répondre à cela, je m'appuierai sur une réponse que j'ai modifiée pour une autre question . Un bon exemple d'URI est la façon dont vous identifiez une ressource Amazon S3. Prenons:
s3://www-example-com/index.html
[figure. 1]
que j'ai créé comme une copie en cache de
http://www.example.com/index.html
[figure. 2]
dans le centre de données d'Amazon S3-US-West-2 .
Même si StackOverflow me permettait de créer un lien hypertexte vers le schéma de s3://
protocole , cela ne vous aiderait pas à localiser la ressource. Parce qu'il identifie une ressource , fig. 1 est un URI valide. Il s'agit également d'un URN valide, car Amazon requiert que le compartiment (leur terme pour la authority
partie de l'URI) soit unique dans tous les centres de données. Il est utile pour le localiser, mais il n'indique pas le centre de données. Par conséquent, cela ne fonctionne pas comme URL.
Alors, en quoi l'URI, l'URL et l'URN diffèrent-ils dans ce cas?
REMARQUE: RFC 3986 définit les URI commescheme://authority/path?query#fragment
Facile à expliquer:
Supposons ce qui suit
L'URI est votre nom
L'URL est votre adresse avec votre nom afin de communiquer avec vous.
je m'appelle Loyola
Loyola est URI
mon adresse est TN, Chennai 600001.
TN, Chennai 600 001, Loyola est URL
J'espère que tu as compris,
Voyons maintenant un exemple précis
http://www.google.com/fistpage.html
dans ce qui précède, vous pouvez communiquer avec une page appelée firstpage.html ( URI ) en utilisant http://www.google.com/fistpage.html ( URL ).
L'URI est donc un sous-ensemble de l'URL, mais pas l'inverse.
Un identificateur de ressource uniforme (URI) est une chaîne de caractères qui identifie une ressource Internet.
L'URI le plus courant est l'URL (Uniform Resource Locator) qui identifie une adresse de domaine Internet. Un autre type d'URI, moins courant, est le nom universel de ressource (URN).
J'ai trouvé:
Un identificateur de ressource uniforme (URI) représente quelque chose d'une grande image. Vous pouvez fractionner les URI / URI peuvent être classés en localisateurs (localisateurs de ressources uniformes - URL), ou en noms (nom de ressource uniforme - URN), ou les deux. Donc, fondamentalement, un URN fonctionne comme le nom d'une personne et l'URL représente l'adresse de cette personne. Donc, pour faire court, un URN définit l'identité d'un élément, tandis que l'URL fournit définit la méthode pour le trouver, finalement, ces deux concepts sont l'URI
Le meilleur résumé technique ( imo) est celui-ci
IRI, URI, URL, URN et leurs différences avec Jan Martin Keil:
Quiconque traite du Web sémantique rencontre à plusieurs reprises les termes IRI , URI , URL et URN . Néanmoins, j'observe fréquemment qu'il existe une certaine confusion quant à leur signification exacte. Et, bien sûr, d'autres l'ont également remarqué (voir par exemple RFC3305 ou rechercher sur Google). Pour être honnête, j'étais même confus au départ. Mais en réalité, la question n'est pas si complexe. Jetons un coup d'œil aux définitions des termes mentionnés pour voir quelles sont les différences:
Un identificateur de ressource uniforme est une séquence compacte de caractères qui identifie une ressource abstraite ou physique. L'ensemble de caractères est limité à US-ASCII à l'exception de certains caractères réservés. Les caractères en dehors de l'ensemble de caractères autorisés peuvent être représentés à l'aide de l'encodage en pourcentage. Un URI peut être utilisé comme localisateur, nom ou les deux. Si un URI est un localisateur, il décrit le mécanisme d'accès principal d'une ressource. Si un URI est un nom, il identifie une ressource en lui donnant un nom unique. Les spécifications exactes de la syntaxe et de la sémantique d'un URI dépendent du schéma utilisé qui est défini par les caractères avant le premier deux-points. [RFC3986]
Un nom de ressource uniforme est un URI dans l'urne de schéma destiné à servir d'identifiant de ressource persistant et indépendant de l'emplacement. Historiquement, le terme faisait également référence à n'importe quel URI. [RFC3986] Un URN se compose d'un identifiant d'espace de nom (NID) et d'une chaîne spécifique d'espace de nom (NSS): urn :: La syntaxe et la sémantique du NSS sont spécifiques spécifiques à chaque NID. À côté des JNI enregistrés, il existe plusieurs autres JNI qui n'ont pas été soumis au processus d'enregistrement officiel. [RFC2141]
Un localisateur de ressource uniforme est un URI qui, en plus d'identifier une ressource, fournit un moyen de localiser la ressource en décrivant son mécanisme d'accès principal [RFC3986]. Comme il n'y a pas de définition exacte de l'URL au moyen d'un ensemble de schémas, "l'URL est un concept utile mais informel", se référant généralement à un sous-ensemble d'URI qui ne contiennent pas d'URN [RFC3305].
Un identificateur de ressource internationalisé est défini de manière similaire à un URI, mais le jeu de caractères est étendu au jeu de caractères codé universel. Par conséquent, il peut contenir tous les caractères latins et non latins, à l'exception des caractères réservés. Au lieu d'étendre la définition de l'URI, le terme IRI a été introduit pour permettre une distinction claire et éviter les incompatibilités. Les IRI sont destinés à remplacer les URI pour identifier les ressources dans les situations où le jeu de caractères codés universel est pris en charge. Par définition, chaque URI est un IRI. En outre, il existe un mappage surjectif défini des IRI aux URI: chaque IRI peut être mappé avec exactement un URI, mais différents IRI peuvent correspondre au même URI. Par conséquent, la conversion de retour d'un URI à un IRI peut ne pas produire l'IRI d'origine. [RFC3987]
IRI is a superset of URI (IRI ⊃ URI)
URI is a superset of URL (URI ⊃ URL)
URI is a superset of URN (URI ⊃ URN)
URL and URN are disjoint (URL ∩ URN = ∅)
RDF permet explicitement d'utiliser des IRI pour nommer des entités [RFC3987]. Cela signifie que nous pouvons utiliser presque tous les caractères dans les noms d'entité. D'un autre côté, nous devons souvent faire face aux premiers logiciels d'État. Ainsi, il n'est pas improbable de rencontrer des problèmes en utilisant des caractères non ASCII. Par conséquent, je suggère d'éviter les noms non URI pour les entités et je recommande d'utiliser les URL URI [LINKED-DATA]. Pour le dire brièvement: utilisez uniquement des URL pour nommer vos entités. Bien sûr, nous pouvons nous référer à des entités existantes nommées par un URN. Cependant, nous devons éviter de créer à nouveau ce type d'identifiants.