Les URI sont à la base d’internet. Pourtant, force est de constater qu’on ne sait en général pas ce que c’est. On sait juste, en gros, que ça commence par http://…
. Ce qui est faux ! Il existe en fait plein de types d’URI, ou plutôt de plans d’URI. Mais qu’est ce qu’une URI au juste ?
URI signifie Uniform Resource Identifier, ce qui donne en français : identifiant uniforme de ressource. Ce qui ne nous dit toujours pas ce que c’est. En simplifiant, on peut dire qu’une URI est une chaîne de caractère qui permet de localiser quelquechose.
L’URL est sans doute la plus connue des URI. Mais il en existe d’autres, dont voici des exemples :
http://svground.free.fr
est une URL classique, localisant un site Web ;ftp://u402639-favoris:motdepasse@tangui.net/favoris.xml
pointe vers mes anciens favoris, mais avec le protocole FTP ;mailto:tangui.lepense@free.fr
pour m’écrire un mail ;xmpp:Tangui@im.apinc.org
pour me joindre sur messagerie instantanée (forcément Jabber ;)) ;file:///home/multimedia/musique/Daft%20Punk/Discovery/Voyager.mp3
histoire de décompresser avec de la bonne musique stockée localement sur le disque dur ;
urn:isbn:2290332518
est la référence d’un (très bon) livre.Parfois, même, on ne connaît pas si bien les URI qu’on croit connaître. http://wam:zyg@site.tv:342/?a=%20a&join#42
est une URI http valide… Vraiment !
On l’a vu, une URI sert à localiser, ou tout du moins à décrire de manière unique une ressource. C’est en quelque sorte une adresse.
Sauf qu’avec une URI data:, c’est un peu spécial. En fait, ce plan ne sert pas à localiser une ressource, mais est cette ressource. Pas moins que ça !
Toutes les données de la ressource que l’URI data: décrit se trouve dans celle-ci. Ainsi, plus besoin d’aller chercher cette ressource, en se connectant et en récupérant un fichier par exemple, la ressource est déjà là ! Et ça fonctionne quel que soit le type de ressource : images, textes, fichiers audios, etc. Pas de différences entre fichiers binaires et fichiers textes : tous deux sont acceptés dans les URI data:.
Les URI data: ont cette forme : data:[<type-mime>[;base64],]<données>
où :
type-mime
est le type mime de la ressource. C’est un argument optionnel, et la valeur par défaut est plain/text;charset=US-ASCII
. Une valeur pas très intéressante donc, à l’heure d’Unicode ;;base64
, est elle aussi optionnelle, nous y reviendrons ;Mais avant tout, il faut savoir que les URI respectent des règles de syntaxe. Ainsi, http://truc.com/dossier 1/
n’est pas correcte car elle contient une espace. Alors comment faire pour introduire dans notre plan d’URI data: des données susceptibles de contenir des espaces blanc ? C’est simple, il suffit de les remplacer ces caractères dits illégaux par des caractères autorisés, en précisant bien sur qu’on a fait ces substitutions.
La première solution consiste à appliquer l’algorithme base64 à notre document. C’est ce qu’indique la présence du ;base64
. Lisez l’article de wikipédia pour en savoir plus. Il existe une fonction PHP, base64_encode qui sait faire le boulot.
Mais que se passe-t-il, me direz vous, si on ne met pas ce paramêtre ? Et bien c’est l’algorithme habituel de remplacement des caractères illégaux dans les URI qui doit être appliqué. C’est par exemple cet algorithme qui tranforme l’espace en la chaîne %20
. En PHP, on utilisera la fonction rawurlencode. Cela induit que les URL doivent aussi respecter ces règles d’échappement. Donc, quand on injecte une variable dans une URL côté serveur, on devrait toujours passer un coup de rawurlencode dessus, sinon on se retrouve avec une URL mal formée, avec des réactions différentes selon le navigateur.
Quant au type mime, rien de plus habituel. On peut en plus rajouter l’encodage, pusique celui par défaut est l’US-ASCII, qui ne permet pas beaucoup de caractères par rapport au robuste utf-8 qui lui les connait tous ! Les types mimes suivants sont corrects :
Maintenant, voici un exemple avec un fichier XHTML : data:application/xhtml+xml;charset=utf-8;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFN0cmljdC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS1zdHJpY3QuZHRkIj4NCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWw6bGFuZz0iZnIiPg0KPGhlYWQ+DQo8dGl0bGU+VW4gdGVzdDwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjxwPkV0IMOnYSBmb25jdGlvbm5lIHZyYWltZW50ICE8L3A+DQo8L2JvZHk+DQo8L2h0bWw+
Et avec un fichier image : Image gif
Sympa non ? Et bien en fait, si. Et vraiment sympa, puisque dans les navigateurs supportant ce plan (tous sauf Internet Explorer en fait, même si Opéra limite la taille d’une telle URI à 4Ko) l’acceptent partout : attribut href, javascript, et CSS ! On peut donc écrire sans problème : list-style-image:url(data:image/gif;base64,R0lGODlhMAAQANQGAP/M///Mmf9mAP+ZZmYzAP/MZv/////MzMzMmcxmZswzAMyZmZkzAMyZZsxmAJlmADMzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAMAAQAAAFryAQjGRpnmiqBsIgvHAsz3RtC4R77zyf98Bg7GcrGAyvgYEVOOqaSCWrR7Q1EQKAIaGAYgVHg0KqoOpux2ajDDU42uNl2Xe2KeUOwdWAWB7jAXM7VXZHAHl6fFAOf2RmPGl8L1cJfAqNco83apUGDYkIeQqXYkoACCN1M4QzRoFvBgCgiGClYWk3rDMOoy+8Zby0Ar3Do6PCMrpCyzTKzM8vBAwQ1NXW19jZ2tsQBCEAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7);
. Ainsi, plus de problème de ressource distante indisponible, et vu qu’une feuille de style n’est (en principe) chargée qu’une fois par le navigateur, il n’y a pas de problème de bande passante.
On peut à partir de là imaginer une extension Firefox qui enregistre les pages en local en remplaçant les références à des fichiers externes par ces URI. On obtient ainsi un document tout en un, comme le pdf, disponible hors-ligne, avec les atouts indéniables de XHTML en terme de légèreté. Et on peut aussi intégrer les pages Web pointées, et même les pages Web pointées par ces pages Web, avec la profondeur qu’on veut. Dans l’absolu, on pourrait contenir l’ensemble du Web de cette façon mais voilà la taille du fichier. :/
Ce plan n’a néanmoins pas que des avantages. D’abord le codage en base64 prend 33% de place en plus, et ça doit être à peu près la même chose pour le codage URI. Ensuite, son décodage est difficile et plutôt lent pour les navigateurs. Ainsi, Firefox crash systématiquement pour les fichiers images trop gros sur mon pc. Bref, cette technique est plutôt conseillée pour les documents courts : petites images, petits fichiers son, et documents XML pas trop longs. C’est dans l’esprit de ce plan d’URI et c’est pourquoi Opéra impose une telle limitation.
Comme je trouve ces URI très pratiques, j’ai écrit un petit script qui permet de faire les conversions facilement. Essayez mon convertisseur de document en URI data:. Et pour ceux qui veulent découvrir une autre manière de coder un site Web, lisez la source.
Ces URI sont bien sûr utilisables avec SVG et partout ou il est possible de mettre une URI !
Voilà pour ce petit bonus, j’espère que ça vous servira. Pensez à rabattre le caquet de ceux qui disent que le PDF est le seul format à pouvoir incorporer tous les documents en un seul fichier : XHTML peut aussi le faire !