Source: http://wunk.me/es/anatomia-de-un-uri-que-es-un-url-urn-etc/
Timestamp: 2017-12-16 07:21:55+00:00

Document:
Anatomía de un URI (¿Qué es un URL, URN, etc.?) – Mi Hermosa Vida
por kadar · Publicada mayo 18, 2017 · Actualizado julio 22, 2017
Esto es parte de una serie más grande titulada, “Cómo programar cualquier cosa: Internet“
¿Qué es un URI, URL, URN, etc.?
El año es 2017 y la Internet se ha convertido en una parte omnipresente de la vida cotidiana de muchas personas. Si su única interacción es a través de un servicio de streaming como Netflix o Hulu para ver sus programas favoritos, o están twitteando sus vidas varias veces al día, Internet tiene su control sobre la mayoría de la gente. Así que podría ser fácil olvidar los primeros días de Internet y los problemas que enfrentan los adoptantes.
Uno de esos problemas fue la capacidad de hacer referencia a los recursos que se pueden encontrar en Internet. Solía ser que si quería describir cómo acceder a algo en Internet que tenía que decirle a la gente a abrir un programa, iniciar sesión como este usuario, navegar a este lugar, entrar en esa información, etc No había manera real de Dirigiéndose a un recurso, como una imagen, una dirección de correo electrónico o un MUCK, como lo haríamos en un sobre con “correo postal”. Sí, así se solía llamar. Sería como escribir una carta y luego decirle a su cartero direcciones a la casa de su amigo en persona para que sea entregado. Eso prácticamente no es práctico.
Afortunadamente, un número de ideas subió a la prominencia que permitió el mismo tipo de direccionamiento que usted encuentra en el mundo real para ser utilizado en la “autopista de la información.” Sí, así se solía llamar. Una de esas ideas fue el Identificador de Recurso Uniforme, también conocido como URI. Puede estar familiarizado con el término URL, o Uniform Resource Locator, que es una forma de URI. También hay la menos conocida URN, o Uniform Resource Name, que también cubriremos.
En esencia, un URI es una forma de “etiquetar” algún tipo de “recurso” en Internet. Esto es un poco abstracto, pero lo explicaré. Un URI no necesariamente especifica una ubicación en una red, como URL, sino que es una especificación de formato para lo que podría utilizar para etiquetar un recurso. Un recurso aquí es cualquier cosa, un PDF, un JPG, un archivo HTML, incluso una conexión, como una conexión telnet. Los recursos pueden incluso ser objetos de datos obtenidos a través de una API REST, como una persona, o un registro de nómina. La idea principal aquí es que puede asignar un “identificador” a un recurso con un URI. Ese URI entonces “se refiere” a ese recurso, y de hecho, el acto de “resolver” un URI no relativo recupera una representación de ese recurso, siendo los datos reales tales como un archivo de imagen.
Por ejemplo, por ejemplo, subo una imagen a Instagram. En los servidores de Instagram esta imagen en particular puede estar ubicada en todo tipo de lugares. Se podría duplicar en varios servidores en todo el mundo, y probablemente se encuentra en una carpeta anidada en particular en el sistema de archivos del servidor. Sin embargo, Instagram me proporciona un URI para esa imagen en particular en la forma de: https://www.instagram.com/p/xxxxxxxxxx donde “xxxxxxx” es un montón de caracteres aparentemente aleatorios (letras). Este bit particular de técnico-ese es un URI, es decir, identifica un recurso particular (imagen) en Internet. Este URI también pasa a ser un URL, en el que también especifica una ubicación de red, pero independientemente de que es un URI.
Otro ejemplo es el número ISBN de un libro. Los números ISBN de libros son identificadores únicos asignados a los libros por varias organizaciones específicas de cada país. Se utilizan en diversos fines comerciales y en los Estados Unidos la empresa privada R. R. Bowker los emite. “La historia interminable” de Michael Ende, uno de mis libros favoritos, actualmente se le asigna el ISBN 0140386335. Una URN es una forma de URI que identifica el nombre de un recurso dentro de un “espacio de nombres”. Se desglosa de izquierda a derecha en especificidad cada vez mayor. Los identificadores de espacio de nombres, como “isbn”, deben estar registrados con la Autoridad de números asignados de Internet (IANA). En este caso la URN para nuestro libro sería urn: isbn: 0140386335.
Ambos ejemplos son ejemplos de URI, es decir, identificadores que se refieren a recursos específicos. Sin embargo, cabe señalar, con el riesgo de complicar las cosas, que un URI no tiene que “referirse” a un documento tangible o recurso, simplemente debe proporcionar un medio de identificación. Por ejemplo, en lo que se conoce como la “red semántica”, los URIs se utilizan para identificar no sólo documentos, sino también abstracciones, conceptos y entidades que se encuentran en el mundo real. El Resource Description Framework utiliza los URI de tal forma que no tienen que implicar la recuperación de representaciones de recursos a través de Internet y, de hecho, pueden incluso no indicar un recurso basado en la red. La clave aquí es que un URI identifica un recurso.
Para los más inclinados técnicamente, los documentos que estoy dibujando en relación con el resto de este artículo son los RFC que primero defind la URI. Estos son RFC2396 y RFC3986 (una finalización de la estructura de un URI). Estos son documentos llamados “Solicitud de Comentarios” que ayudan a definir la mecánica y las normas de Internet.
Los significados de Uniforme, Recurso e Identificador
URI significa identificador de recurso uniforme. Se llama así debido a sus tres características homónimas, que siendo, la uniformidad, sus recursos referentes, y su naturaleza de identificación.
Por ejemplo, la uniformidad es el hecho de que cada identificador sigue un diseño particular, haciéndolo uniforme. Esto significa que los URIs siguen una sintaxis particular, y pueden ser “analizados” y entendidos por varios programas y usuarios, dándoles una buena idea del recurso en cuestión. Esto les da un cierto contexto propio que les permite ser utilizados en otros contextos junto a otros, es decir, la capacidad de identificar los recursos dispares con un formato. Cito RFC3986:
La uniformidad proporciona varios beneficios. Permite utilizar diferentes tipos de identificadores de recursos en el mismo contexto, incluso cuando los mecanismos utilizados para acceder a dichos recursos pueden ser diferentes. Permite una interpretación semántica uniforme de convenciones sintácticas comunes a través de diferentes tipos de identificadores de recursos. Permite la introducción de nuevos tipos de identificadores de recursos sin interferir con la forma en que se utilizan los identificadores existentes. Permite que los identificadores sean reutilizados en muchos contextos diferentes, permitiendo así que nuevas aplicaciones o protocolos aprovechen un conjunto preexistente, grande y ampliamente utilizado de identificador de recursos.
Los recursos, como se analiza en la introducción, pueden ser prácticamente cualquier cosa. Estamos más familiarizados con los recursos que tenemos acceso a través de Internet, como un PDF o una imagen. Eso se puede resumir un poco y también apuntar a un recurso que sirve un “propósito consistente”, como “el tráfico en I-25 hoy”. Sin embargo, como se señaló en el último párrafo de la introducción, un recurso no siempre es siempre accesible en este sentido tradicional, y de hecho puede ser identificador para personas, libros, corporaciones, conceptos abstractos, etc.
Entonces, ¿qué es exactamente un identificador? Una vez más citar RFC3986 como lo ponen sucintamente:
… Un identificador incorpora la información necesaria para distinguir lo que se identifica de todas las demás cosas dentro de su ámbito de identificación. Nuestro uso de los términos “identificar” e “identificar” se refiere a este propósito de distinguir un recurso de todos los demás recursos, independientemente de cómo se cumpla ese propósito (por ejemplo, por nombre, dirección o contexto). …
Es decir, un identificador es básicamente una forma de referencia de identidad. Es decir, el nombre de un recurso dado. Por ejemplo, su identidad es la de un ser humano, presumiblemente, pero su identificador sería su nombre, como el mío, Asher Wolfstein. Podemos llamar a cualquier cosa o grupo de cosas por cualquier nombre, y ese sería su identificador. Esto significa que no podemos asumir que el identificador o nombre define lo que se hace referencia, ya que podemos nombrar cualquier cosa que queramos, bueno, cualquier cosa que queramos. Por ejemplo, la Casa Atreides de la serie de libros Dune no necesariamente identifica un único hogar o domicilio real, sino un grupo entero de individuos. Y como se señaló anteriormente, dado que un recurso no necesariamente puede ser “accesible”, digamos por Internet, un identificador puede ser definido sin ningún medio o intención de “acceder” a él. Así podría crear un identificador para el número cero, o el color rojo. ¡Usted no “accedería” al color rojo en su navegador web!
Globalidad y “Contexto del usuario final”
Normalmente, los URIs significan como finalizar todos los identificadores para cualquier recurso al que se refieran. Lo que esto significa es que no hay ningún contexto adicional para que un URI comprenda un URI. Por ejemplo, el URI “http://wunk.me/” identifica mi página de inicio de mi blog, no importa cómo se accede a ella, que identifica mi página de inicio. No obtendrá un resultado diferente dependiendo de lo que utilice para acceder a él, que sería un ejemplo de un contexto adicional.
Sin embargo, el resultado de la interpretación de un URI particular puede depender del contexto de un usuario final. El RFC menciona como ejemplo el URI “http: // localhost /” que normalmente apunta a la máquina host del usuario final:
… Por ejemplo, “http: // localhost /” tiene la misma interpretación para cada usuario de esa referencia, aunque la interfaz de red correspondiente a “localhost” puede ser diferente para cada usuario final: la interpretación es independiente del acceso. …
En este caso, localhost significa indicar la máquina host local que el usuario está ejecutando, no cualquier computadora específica en el mundo. Además, la especificación implora que “los URI que identifican un recurso en relación con el contexto local del usuario final sólo deben usarse cuando el contexto en sí mismo es un aspecto definitorio del recurso”. Puede ver esto en el caso de un URI de sistema de ficheros que comience con “file: //” Este tipo de URI identifica un fichero en una carpeta particular en la máquina de un usuario, y la misma definición se basa en el sistema de ficheros de la máquina de un usuario. Puedo usar, como sugiere la especificación, este tipo de URI en un manual de ayuda cuando el archivo se instala en la máquina de un usuario, pero no lo usaría en un manual de ayuda en línea que reside en un sitio web para hacer referencia a otros documentos en el sitio web.
Estructura de un identificador de recurso uniforme (URI)
La especificación URI espera proporcionar una “sintaxis general” para el análisis y comprensión de URIs. Esto significa que los “tipos” específicos de URIs, que siendo URIs de diferentes esquemas, pueden restringir o redefinir más la sintaxis o formato para ellos mismos, pero en general las directrices y el formato general permanecen los mismos en todas partes. Por ejemplo, el URI mailto:test@test.com y el URI ftp://ftp.test.com/remotefolder son de dos formatos diferentes para dos esquemas diferentes, pero dependen de un formato general subyacente.
La sintaxis general de un URI se especifica en la siguiente cadena:
Esto se toma de wikipedia, que tiene un excelente artículo sobre URIs. La idea es que cada palabra presente el nombre para ese componente particular de la URI, y los corchetes indican componentes anidados que pueden o no estar necesariamente presentes. Por ejemplo, no es necesario tener un usuario: componente de contraseña presente para acceder a todas las páginas web.
Como se puede ver en la sintaxis general anterior, hay ciertos caracteres que se reservan en general para URIs para usar, y que los sistemas que implementan los URIs específicos deben evitar el uso. Estos caracteres se definen en el RFC como sigue:
Cualquier cosa arriba contenida entre comillas no debe ser usada en un URI a menos que se especifique lo contrario por el formato del esquema. También debería, por convención, evitar espacios en su URI, ya que puede indicar otro URI o diferente. Si debe utilizar estos caracteres en los componentes de un URI, como en el componente de ruta de acceso, debería utilizar la representación “porcentaje codificado” de ese carácter.
Porcentaje de codificación
Hay formas de incluir caracteres en un URI que un algoritmo descifrar que URI puede utilizar sin infringir ningún carácter reservado, y que es a través de la codificación porcentual. Para citar el RFC:
Se utiliza un mecanismo de codificación de porcentaje para representar un octeto de datos en un componente cuando el carácter correspondiente de dicho octeto está fuera del conjunto permitido o está siendo utilizado como delimitador o dentro del componente.
Esto generalmente toma la forma de:
Lo que se traduce es un signo de porcentaje seguido de un dígito hexadecimal (0-F) y otro dígito hexadecimal (0-F). Hexadecimal es un sistema de números base-16 que usa los números 0-9 y las letras A-F. Para obtener más información sobre hexadecimal, consulte mi tutorial sobre el tema.
En esencia, se especifica un carácter codificado US-ASCII a través de hexadecimal en lugar de escribirlo directamente. Por ejemplo, para representar un espacio, que en US-ASCII está representado por la secuencia binaria “00100000”, se utilizaría “%20”
Sintaxis y componentes
El RFC realmente define la sintaxis general de un URI usando lo siguiente:
Aquí puede ver que [//[user[:password]@]host[:port]] correspondería realmente a la “hier-part”, o jerarquía, de un URI. La parte jerárquica está compuesta por un componente de autoridad y un componente de ruta. Cuando no hay dos barras diagonales dobles, se puede ver que la parte de autoridad está omitida y nos basamos sólo en el componente de ruta.
El RFC define el elemento de autoridad de un URI utilizando lo siguiente:
El elemento de autoridad se denomina elemento de autoridad porque delega a una “autoridad de nomenclatura”. Por ejemplo, para la mayor parte de Internet, en lugar de depender de números misteriosos y esotéricos para dirigirse a servidores como 145.23.43.78, usamos nombres de dominio. Los nombres de dominio son controlados por la Corporación de Asignación de Nombres y Números de Internet (ICANN), que en este caso emplea varios métodos para traducir un nombre de dominio a una dirección de red detrás de las cortinas. ICANN es entonces la “autoridad” que dirigiría la resolución de un URI utilizando como una autoridad para resolver dicho URI. Es decir, en mi URI http://wunk.me/home/, “wunk.me” es el elemento de autoridad del URI, y la resolución del elemento de autoridad iría a ICANN, o quien corresponda, cuando se resuelva el URI (Es decir, en este caso, se accede).
Muchos servicios en Internet son ejecutados por servidores, que son sólo configuraciones especiales de computadora que permiten que los recursos sean “servidos” a través de la red, como documentos de páginas web y tal. Por lo tanto, para muchas autoridades es una cuestión de dónde un nombre registrado conduce a, a continuación, en qué puerto se accede a ese servicio, y en algún momento que el usuario está accediendo a ese puerto.
Así que por ejemplo, si yo era el usuario “asher” en el nombre de dominio wunk.me acceder al puerto del servidor 80 (que es el puerto de los servidores web en general, uso) que tipo de utilizar el siguiente como mi elemento de autoridad en mi URI: “asher @ wunk “Mi URI en su totalidad podría leer:” http: //asher@wunk.me: 80 / home / “.
Si un elemento de autoridad está presente en un URI, está precedido por una barra doble “//”, y se termina con la siguiente barra diagonal, signo de interrogación o número, o al final de la URI. Si una autoridad no está presente en un URI, no se requiere un precedente de doble barra.
Por lo tanto, para construir en nuestra sintaxis suministrada wikipedia se puede leer el URI de la siguiente manera:
hierarchy _________________|____________________ / authority \ ______________|________________ / \ scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
RFC3986 hace una mención de “jerarquía” en el formato URI:
La sintaxis de URI se organiza jerárquicamente, con componentes enumerados en orden decreciente de izquierda a derecha.
Lo que esto significa es que un URI generalmente define las delimitaciones más significativas en primer lugar, como el esquema, la autoridad (como un nombre de dominio en HTTP) y, a continuación, una ruta de acceso a un elemento determinado, como un archivo. En los archivos de Internet y los recursos se organizan a menudo en las modas jerárquicas, que un URI puede aprovechar dependiendo de su esquema. Muchos formatos URI populares, como el protocolo de transferencia de hipertexto (HTTP) de la web o el protocolo de transferencia de archivos (FTP), se basan en mecánica abstracta del sistema de archivos. Es decir, cada recurso está encerrado en una carpeta que puede estar encerrada en otras carpetas y así sucesivamente. En general, la mayoría de los sistemas de archivos le permiten rastrear hacia arriba y hacia abajo la estructura de archivos utilizando indicadores como “..” (subir una carpeta), y estos tipos de URI son los mismos en su componente de ruta de acceso. Esto significa que es posible que un URI pueda ser relativo en un sistema de documentos o recursos. Es decir, una página HTML en un sitio web puede referirse a “../about/index.html” que se traduciría esencialmente en “mover una carpeta arriba, entrar en la carpeta about y acceder a index.html”
La razón por la que esto es importante es porque podemos mezclar y combinar los componentes de la ruta con componentes más fundamentales como esquema y autoridad. Lo que esto significa es que podemos acceder a una página web a través de HTTP para ver en un navegador web, como http://wunk.me/about/asher.html, pero también podemos acceder a ella a través de FTP en un cliente, como Ftp://ftp.wunk.me/about/asher.html. Incluso podríamos acceder a él en nuestro ordenador local con file: //home/asher/wunk/about/asher.html. El componente de ruta sigue siendo el mismo mientras que el esquema y la autoridad cambian.
En estos casos, dependiendo del esquema y del formato específico del URI, hay caracteres particulares que son útiles para distinguir la jerarquía de especificidad: “/”, “?” Y “#”. La forma en que se utilizan estos caracteres exactos depende del formato y del esquema URI, pero estos caracteres son comunes en todos los URIs para ayudar a diferenciar las relaciones jerárquicas en los sistemas de recursos. Por ejemplo, el carácter “/” es útil en los esquemas de archivo, ftp y http para indicar que se está accediendo a una carpeta o directorio en particular.
A partir de izquierda a derecha podemos examinar cada uno de los componentes específicos de un URI:
En el RFC la sintaxis de un esquema se define mediante:
Lo que esto significa básicamente es que un esquema comienza con una letra, que puede ser seguida por otra letra, un dígito o los caracteres “+”, “-” o “.”. No definido anteriormente, pero más arriba en las otras definiciones, el esquema en un URI es seguido por dos puntos “:”.
Tenga en cuenta que el componente de esquema en una URI se refiere a una especificación para asignar identificadores dentro de ese esquema. Esto es importante notar, y lo que significa es que un esquema puede compartir el mismo nombre que un protocolo (como HTTP), pero eso no significa que tiene equivalencia con un protocolo. El esquema en relación con la URI define el formato de la URI, como por ejemplo la forma en que el esquema “urna” cambia el formato (como veremos más adelante). Esto significa que un nombre de esquema puede no ser el mismo que el protocolo utilizado en su método de recuperación. Un URI que empieza con mailto: puede indicar una dirección de correo electrónico, pero no define un protocolo mailto para acceder a esa dirección de correo electrónico.
Esto es parte del elemento de autoridad del URI y se proporciona como un medio para autenticarse al servicio en cuestión. La parte de contraseña de este componente está obsoleta, lo que significa que ya no está destinado a ser utilizado, ya que es muy inseguro (cualquier cosa que imprime contraseñas al aire libre, y mucho menos transmite es inseguro). Esto es útil para servicios y servidores que operan con cuentas de usuario. Sigue el carácter reservado “@”.
Esta es la parte principal del elemento de autoridad de un URI. El host puede estar en muchos formatos, desde una dirección IPv4 (como esta: 10.0.0.1), un nombre de dominio que se resuelve a una dirección IPv4, una dirección IPv6 (que debe estar entre paréntesis) y tal. Su trabajo principal es apuntar hacia un servicio o servidor que puede resolver aún más el URI en un recurso en particular. Para los URI que no se asignan a recursos de red específicos, el nombre de host puede servir como más de una URN (véase más adelante), o tal vez apuntar a un documento que explique el uso de la URI en general.
Esto es parte opcional del elemento de autoridad de un URI, y está precedido por dos puntos cuando está presente. La mayoría de los sistemas informáticos en estos días hablan entre sí sobre las redes mediante la implementación de lo que se llaman puertos. Un puerto es esencialmente una identificación de un “canal” sobre el cual dos entidades se comunican. Al igual que yo podría marcar mi radio al canal 94.3 para escuchar una estación de radio de rango frontal en particular, un programa en una computadora puede instruir a la computadora a “enlazarla” a un puerto específico (por ejemplo, el puerto 8080) Que se destina al puerto 8080 será redirigido a ese programa. Por ejemplo, digamos que ejecute un servidor web en una computadora. Lo enlazamos al puerto 80, ahora cualquier computadora que pida http: // mycomputer: 80 / enviará una petición HTTP GET al puerto 80 de mi computadora. Simplemente sucede que el puerto 80 es el puerto predeterminado para los servidores web, y muchas veces cuando se especifica un nombre de dominio en un navegador web se supone que significa el esquema “http”, y el puerto 80.
Otros servicios se ejecutan en otros puertos predeterminados. Algunos protocolos tienen números de puerto diferentes como sus valores predeterminados, y los programas de servidores que ejecutan esos servicios a menudo se enlazan a esos puertos de forma predeterminada. También puede tener programas de servidor para servicios especializados, como MUD o ​​MUCK, que se ejecutan en puertos personalizados como 237911. Diga que estaba ejecutando un MUD tal en mi servidor, puede acceder a él de la siguiente manera: telnet://wunk.me:237911/.
El componente de ruta de acceso contiene normalmente información jerárquica, como un archivo ubicado en subcarpetas en un sistema de archivos. Es por eso que es parte del elemento de jerarquía en la especificación URI. La ruta no necesariamente tiene que ser jerárquica, o una ruta de acceso a un archivo específico. Sin embargo, por lo general lees la forma de información de la ruta de izquierda a derecha, desde la más significativa / menos específica a la más específica / menos significativa. Ése es el componente de la trayectoria whittles para abajo especificidad hasta que usted está señalando en una cosa particular. Al combinar la ruta con el componente de consulta (ver más abajo) tiene un URI específico.
La ruta se termina por el primer signo de interrogación o signo numérico, o el final de la URI. Si el URI tiene un elemento de autoridad entonces el elemento path debe comenzar con una barra o estar vacío. Si el elemento de autoridad falta en un URI, entonces la ruta no puede comenzar con una barra doble. Si una referencia URI es una referencia de ruta relativa, el primer segmento de ruta no puede contener un carácter de dos puntos. Si necesita dos puntos, es aquí donde el porcentaje de codificación puede resultar útil.
Aquí es donde las cosas se vuelven mucho más interesantes en lo que respecta a la URI de nuevo. Una consulta es básicamente información no jerárquica codificada en un URI. Esta información se transmite a un servicio, por lo general, que procesa aún más para hacer algo específico.
Tomemos por ejemplo google. Cuando escribe una búsqueda en google, va a esta URL:
Como se puede ver ahora, https es el esquema, www.google.com es la autoridad (host), / search es la ruta que es, nuestro recurso. Todo después del signo de interrogación es la consulta. Sus palabras de búsqueda no son una parte jerárquica de la estructura de información, sino que son parámetros que pasa al recurso / search. Q = tu + búsqueda + aquí es procesado por el recurso de búsqueda en el dominio google para producir la página HTML resultante que ves en tu navegador.
Las consultas no tienen que usarse únicamente como parámetros para servicios, sino que pueden representar cualquier dato no jerárquico que sea pertinente para el identificador. Hay un “estándar” de formato para parámetros de consulta sin embargo, no en la especificación RFC para URL. Generalmente se entiende que los parámetros de consulta vienen en la forma:
Esencialmente esto asigna un valor a una clave, varias veces (por lo tanto a varias claves diferentes). El signo es el separador entre pares clave-valor. Ésta es la noción generalmente aceptada, sin embargo, dependiendo de cómo su servidor interpreta valores de la consulta esto no se fija en piedra. Además, los valores de consulta en URI no accesibles (por extraño que parezca) no tienen realmente ninguna noción de formato en particular.
Sin embargo, el RFC advierte sobre el formato de los valores de consulta:
Sin embargo, como los componentes de consulta se usan a menudo para llevar información de identificación en forma de pares “clave = valor” y un valor usado con frecuencia es una referencia a otro URI, a veces es mejor para usabilidad evitar la codificación porcentual de esos caracteres.
El componente de identificador de fragmento de un URI es una manera de identificar indirectamente un recurso secundario dentro de un recurso principal u otra información de identificación adicional. Si desea que su URI de recursos tenga un contexto, esta es la forma de hacerlo. El URI primario antes del fragmento es el URI primario mientras que el fragmento es el identificador secundario o subordinado. El fragmento podría referirse a una parte del recurso primario, o tal vez una “vista” particular sobre las representaciones del recurso primario. Teóricamente podría ser incluso algún otro recurso que sea definido por el recurso primario.
Este identificador es indicado por la presencia de un carácter de signo de libra y terminado por el final de la URI. Siempre viene al final de la URI.
Debido a su naturaleza como identificador de recurso secundario, los identificadores de fragmentos se definen semánticamente de acuerdo con el recurso primario. Esto es, es “definido por el conjunto de representaciones que pueden resultar de una acción de recuperación en el recurso primario”. Por lo tanto, el formato del fragmento depende del tipo de medio de una representación recuperada, no necesariamente el formato del mismo.
Puede pensar en el fragmento como una forma de sub-referenciación de documento, o una consulta para el recurso en cuestión. Mientras que una consulta se aplica al recurso en la mano en el URI, siendo parte de la URI, el fragmento se aplica al recurso en sí, no siendo realmente parte de la URI. El fragmento está destinado a ser utilizado en la resolución de un URI, después de la “dereferencing” por así decirlo. Si no existe tal representación de un recurso, el identificador de fragmento se considera desconocido y está “sin restricciones”. Los identificadores de fragmentos de esta manera son independientes del esquema URI, ya que están vinculados al formato del documento, como HTML, y no pueden redefinirse por el esquema.
Por tanto, corresponde a los tipos de medios definir sus propias restricciones o estructuras del identificador de fragmentos. Por ejemplo, HTML especifica un fragmento para apuntar a un elemento “a” (ancla) de un documento HTML. El esquema http: no tiene nada que ver con esto, como un http: URI podría referenciar una imagen tan bien como un documento HTML.
Un Uniform Resource Locator (URL) es un tipo de URI. Aunque el término es considerado obsoleto ahora por muchos técnicos, todavía mantiene un amplio uso popular. Una URL es esencialmente lo que hemos cubierto en cuanto a lo que constituye un URI, su alcance es ligeramente diferente.
Una URL especifica que lo que está identificando es accesible y aplicable a través de una red, en particular Internet. Es decir, implica que cualquier cosa que el URI identifique sea accesible y recuperable desde Internet.
Hay una peculiaridad de URL y que es la URL sin esquema o sin protocolo. Esa es una url que comienza con una barra doble, con un elemento de autoridad, pero falta el esquema. Cuando un navegador web encuentra ese tipo particular de URL a menudo lo accederá usando el mismo
Nombre del recurso uniforme
Uniform Resource Name, o URN, se describieron por primera vez y se definen en RFC1737 y RFC2141. Se han actualizado para los tiempos modernos en RFC8141. En los primeros días de la gente de Internet todavía estaban luchando con exactamente cómo todo el asunto iba a funcionar. URN originalmente fueron concebidos como uno de una arquitectura de tres partes para el Internet en general, incluso la web. Las tres partes debían ser URLs, URNs y Uniform Resource Characteristics (URC). A diferencia de las direcciones URL, que especifican la ubicación de un recurso y cómo acceder a él (a través de una asignación del esquema a un protocolo, como HTTP y FTP), se piensa que URN son identificadores definidos mediante el uso de globalmente único y persistente Namespaces Para los interesados, los URC nunca pasaron de la fase de la idea, con otras tecnologías, como el Marco de Descripción de Recursos que ocupa su lugar.
Las URN pueden ser muy parecidas a los nombres de dominio, aunque los nombres de dominio no son técnicamente URN. Lo que quiero decir con esta analogía, sin embargo, es que cada uno especifica un identificador a través del uso de “espacios de nombres”. Ese identificador se refiere o “señala” a algo permanente que puede o no existir actualmente o ser accesible. Eso es lo que los hace persistentes y, por tanto, globales.
Por ejemplo, lee un nombre de dominio de derecha a izquierda, en orden de especificidad cada vez mayor. Por ejemplo, www.wunk.me se lee primero, el espacio de nombres me (dominio de nivel superior), wunk como ese nombre particular en el espacio de nombres me y www es el servicio particular que se ejecuta en wunk.me. Del mismo modo, de izquierda a derecha, se leería una urna con el mismo tipo de especificidad creciente, como urn: isbn: 0140386335. Primero identificamos el espacio de nombres de isbn, y dentro del namespace isbn identificamos el código numérico. En este caso esta es una urna para el libro “The Neverending Story” de Michael Ende. No podemos necesariamente levantar, recuperar o acceder al libro utilizando esa URN (que es un URI), pero podemos “identificar” el libro en cualquier forma que pueda existir en cualquier momento con otro nombre: urn: isbn: 0140386335 .
En este sentido “The Neverending Story” de Michael Ende y urn: isbn: 0140386335 son dos “nombres” para la misma entidad. En el contexto de la información anterior con respecto a URIs entonces usted puede ver que “urn:” es otro esquema por el cual podemos formatear URIs. La última versión de la especificación URN incluye algunos elementos que los URIs se definieron más tarde, incluyendo los componentes q y los componentes f (véase más adelante).
Las URN, como las URL, pueden ser “resueltas” dado algún tipo de servicio de resolución. El servicio de resolución puede ser el proveedor del identificador del espacio de nombres (véase más adelante), o puede ser un servicio de propósito general como una biblioteca. Por ejemplo, una biblioteca podría resolver la URN del libro anterior a una dirección URL que apunte a una lista del libro en sus archivos, o si ese libro no existe en los archivos, tal vez una URL para una lista del libro con una línea librero. Del mismo modo, al igual que con otros URIs, algunas URNs no son solucionables ni pretenden ser solucionables, y existen puramente como identificadores que hacen referencia a una entidad tal vez abstracta.
Estructura de un nombre de recurso uniforme (URN)
RFC8141 define la sintaxis URN y el formato utilizando aumentado backus-naur forma de la siguiente manera:
namestring = assigned-name [ rq-components ] [ "#" f-component ] assigned-name = "urn" ":" NID ":" NSS NID = (alphanum) 0*30(ldh) (alphanum) ldh = alphanum / "-" NSS = pchar *(pchar / "/") rq-components = [ "?+" r-component ] [ "?=" q-component ] r-component = pchar *( pchar / "/" / "?" ) q-component = pchar *( pchar / "/" / "?" ) f-component = fragment
Usted puede destilar esto abajo a algo más como esto (como lo hicimos anteriormente para URIs):
“Nid” es el identificador del espacio de nombres, y puede incluir letras, dígitos y el carácter de guión “-“. La cadena específica de espacio de nombres, “nss”, es una cadena de caracteres que se formatean de acuerdo con el identificador de espacio de nombres. Piense en el identificador del espacio de nombres como algo el “esquema” de la URN, mientras que el NSS es el identificador específico en cualquier formato es específico a ese “esquema”. Por ejemplo, en la URN urn: isbn: 0140386335, “isbn” es el identificador de espacio de nombres, y la cadena de espacio de nombres específica es 0140386335, o una cadena de 10 dígitos.
Los espacios de nombres oficiales, la parte “nid” del formato URI de la urna, deben registrarse en la IANA. Los espacios de nombres pueden ser “formales” o “informales”. Un espacio de nombres formal es en realidad un identificador, como “isbn”. Hay aproximadamente sesenta identificadores de espacio de nombres URN formales y cubren varios temas y motivos. La idea general es que los usuarios pueden “beneficiarse de su publicación”. Los espacios de nombres formales están restringidos de varias maneras, la mayoría de las cuales son obvias. No pueden ya estar registrados, no pueden comenzar con “urna-“, deben tener más de dos letras de largo (incluyendo el guión, que es “ab-” o “xy-” no está permitido), y no pueden, Por razones obsoletas, no puede comenzar con un prefijo “x-“.
Los espacios de nombres “informales” son simplemente un número y no traicionan su propósito en la inspección superficial. Los namespaces informales residen en el formato “urn-“, siendo “urn-0123456789” o “urn- #”. El número se asigna por orden de llegada por primera vez por la IANA.
El tipo obsoleto de URN es el espacio de nombres URN experimental que comenzó con un “x-“. Esto ha sido obsoleto por RFC8141 y en su lugar los autores preferirían usar urn: example namespace.
Todos los espacios de nombres, formales, informales y experimentales, se pueden emplear en cualquier lugar donde se espera un URI como identificador para un recurso en particular.
Cuerdas específicas de espacio de nombres
Las cadenas específicas del espacio de nombres o la parte “nss” de la especificación URN, están determinadas por el espacio de nombres en cuestión. Según el ejemplo en ejecución, un número de diez dígitos compone la cadena específica del espacio de nombres para el espacio de nombres “isbn”. Otros espacios de nombres tienen formatos amplios y variables que se permiten en la cadena de espacio de nombres específicos. El NSS puede contener letras ASCII, dígitos y muchos signos de puntuación u otros caracteres especiales. Como con cualquier URI como el anterior, cualquier carácter no permitido en un NSS puede codificarse por ciento (ver arriba). El RFC8141 aumentó el número de caracteres permitidos en un NSS para incluir el carácter de barra “/”. Este carácter de barra no indica necesariamente datos jerárquicos, como un elemento de ruta de acceso, simplemente permite que los nombres de sistemas no URN que usan barras se incluyan.
Componente Q
RFC8141 agregó lo que se conoce como el “elemento-q”. Esto se puede comparar con el componente de consulta de un URI genérico como se ha indicado anteriormente. De hecho, en algunos casos, como cuando el URN es resolúble a otro URI, puede terminar copiando el elemento q en la consulta del URI. No se puede hacer que un identificador URN dependa de un elemento q, lo que significa que el identificador debe ser capaz de mantenerse por sí solo sin un elemento q para encapsular lo que representa. Esto es lo que el RFC tiene que decir:
El componente q de URN tiene la misma sintaxis que el componente de consulta URI pero se introduce con “? =”, No “?” solo. Para una URN que puede resolverse en un URI que sea un localizador, la semántica del componente q es idéntica a la del componente de consulta de ese URI. Por lo tanto, los resolvedores URN que devuelven un URI que es un localizador para una URN con un componente q hacen esto copiando el componente q desde la URN al componente de consulta de la URI.
Sin embargo, una diferencia con el componente de consulta de URI en la sintaxis general se describe en el RFC:
Los caracteres slash (“/”) y signo de interrogación (“?”) Pueden representar datos dentro del componente q. Tenga en cuenta que los caracteres fuera del rango ASCII DEBEN estar codificados por ciento
Para obtener más información sobre el porcentaje de codificación, consulte la sección anterior en la sintaxis URI general.
El componente f es muy similar al componente de fragmento de una URI de sintaxis general. De hecho, cuando una URN puede resolver a un URI, el componente f puede ser aplicado como el fragmento de ese URI. El componente f, al igual que el componente de fragmento, se utiliza para referirse a las partes constitutivas de un recurso identificado por la URN. Por ejemplo, una URN para un libro puede dividir capítulos utilizando un componente f. Tal como, urn: isbn: 0140386335 # chapter5, para referirse al quinto capítulo de The Neverending Story.
Para citar el RFC en lo que respecta a la similitud del componente f con el componente fragmento de una sintaxis general URI:
El componente f de URN tiene la misma sintaxis que el componente de fragmento URI. Si un URN que contiene un componente f resuelve un URI único que es un localizador asociado con el recurso con nombre, el componente f de la URN puede ser aplicado (normalmente por el cliente) como el fragmento de ese URI. Si la URN no resuelve un URI que es un localizador, la interpretación del componente f no está definida por esta especificación. Por lo tanto, para URNs que pueden ser resueltos a un URI que es un localizador, la semántica de f-componentes son idénticos a los de los fragmentos de ese recurso.
El “elemento-r” no está estandarizado actualmente, pero la intención es que contenga parámetros que pasaría a la “resolución” de una URN. El uso del elemento-r debe ser retrasado hasta que su formato y uso pueda ser mejor entendido, pero la idea es que el componente-r sería usado para “controlar” el resolver en lugar de controlar la representación recuperada de una URN particular. Esto suena ofuscado, y afortunadamente RFC8141 da un ejemplo, cito:
Considere el ejemplo hipotético de pasar parámetros a un servicio de resolución (por ejemplo, un código de país ISO alfa-2 … para seleccionar el país preferido en el que buscar una copia física de un libro). Esto posiblemente podría lograrse especificando el código de país en el componente r, dando como resultado URN, tales como:
Mientras que lo anterior debe servir como una explicación general e ilustración de la intención de r-componentes, hay muchos problemas abiertos con ellos, incluyendo su relación con los mecanismos de resolución asociados con el espacio de nombres URN en particular en el momento de la inscripción. Por lo tanto, r-componentes NO DEBE ser utilizado para URNs antes de su semántica han sido normalizados.
Otros esquemas URI y URN
Hay más URN / URI esquemas que sólo la sintaxis general y la “urna:” esquemas utilizados hoy en día. Estos otros esquemas de URI incluyen tag :, info :, y ni: y son generalmente URN también (en contraposición a URLs). “Tag:” URNs se usan comúnmente en YAML, mientras que “info:” es un esquema muy similar a “urn:” pero responde a otras necesidades. “Info:” fue obsoleto en 2010 y se animó a los usuarios a adoptar otros formatos para sus necesidades.
Así que ahí lo tienes, Uniform Resource Identifiers (URI) s son cadenas de caracteres que “identifican” un particular “recurso” como se definió anteriormente. Los URI pueden o no ser “solucionables” en el sentido de poder unir o acceder a un recurso en particular, e incluso pueden significar algo abstracto que no puede “físicamente” existir. Uniform Resource Locators son ejemplos de URIs que se utilizan en Internet y navegadores web, por ejemplo, para “localizar” los recursos reales que son accesibles a través de redes. El término URL es obsoleto por profesionales técnicos, pero aún en uso popular. Los nombres de recursos uniformes están en el otro extremo, identificando un recurso persistentemente pero no necesariamente un “localizador” para ese recurso. Por ejemplo, podríamos tener la notación Dewey Decimal, o el número ISBN de un libro y encapsular eso en una URN como urn: isbn: 0140386335. Esta URN se refiere a un libro en particular si puede o no existir en un sitio web, una red, una biblioteca, etc.
Si usted aprecia mis tutoriales, por favor, ayúdenme a apoyar a través de mi Patreon.
Etiquetas: EsquemaExplicadoIdentificador Uniforme de RecursosLínea de comandoLocalizador Uniforme de RecursosNombre del recurso uniformeRFCTutorialURIURLURN
Siguiente historia Pokémon GO Redondeo 15
Historia previa Serie de Juego: Dragon Warrior (NES) Episodio 5
Abra Binario C Clock Tower Clock Tower II: The Struggle Within Compiladors Contando Descripción general del juego Dragon Quest Dragon Warrior Eevee Ensamblador Episodios Geodude Introducción Intérpretes iPhone Jennifer Simpson Línea de comando Mankey Memoria NES Nidoran Nintendo Ordenadores Paras Película PHP Pidgey Playstation Pokemon GO Pokémon Programación PSX Python Rattata salud mental Serie de juegos SNES Spearow Tutorial Vamos a jugar Venonat Video Zubat

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución