Comprendre comment les espaces sont codés : %with encodeURI vs. with URL

Vous pouvez encoder une chaîne de requête en utilisant soit encodeURI, soit URL. Récemment, j'ai remarqué que l'URL encode les espaces différemment. Je vais expliquer pourquoi ils gèrent l'encodage de manières distinctes. Avant de plonger dans le sujet, je vais vous montrer comment encoder en utilisant chaque méthode.

---

Usage

1. encodeURI

// 'https://www.google.com/search?q=programming%20language'
encodeURI('https://www.google.com/search?q=programming language')

Vous pouvez encoder un URI à l'aide de la fonction encodeURI. Cependant,. il n'encode pas une partie des caractères qui sont des parties valides d'un URI, de sorte que vous devrez peut-être utiliser la fonction encodeURIComponent pour encoder correctement les chaînes de requête ou les autres composants de l'URI.

Par exemple, disons que vous avez une chaîne de requête q avec la valeur
https://www.google.com/search?q=quelle est la signification de &?.

// 'https://www.google.com/search?q=what%20is%20the%20meaning%20of%20&?'
encodeURI('https://www.google.com/search?q=what is the meaning of &?')

Le &(esperluette) n'est pas converti en & comme il devrait l'être. Parce que &(esperluette) peut être une partie valide de l'URI. Pour cette raison, il est toujours plus sûr d'utiliser encodeURIComponent pour les chaînes de requête.

const url = encodeURI('https://google.com/search');
const queryString = `?q=${encodeURIComponent('what is the meaning of &?')}`;
// 'https://google.com/search?q=what%20is%20the%20meaning%20of%20%26%3F';
url+queryString;

Puisque encodeURIX et les fonctions associées traitent l'URI comme une chaîne, vous devez gérer les caractères spéciaux comme ? et & vous-même. Alternativement, vous pouvez simplifier le processus en utilisant l'URL.

---

2.URL

Lorsque vous utilisez une URL pour encoder, vous devez gérer séparément l'URL de base et la chaîne de requête.

const url = 'https://www.google.com/search?q=programming language';
// 'https://www.google.com/search?q=programming language'
url.toString();

Si vous encodez tout en même temps à l'aide du constructeur d'URL, comme indiqué dans l'exemple ci-dessus, la chaîne de requête risque de ne pas être encodée correctement.

const url = new URL('https://www.google.com/search');
url.searchParams.set('q', 'programming language');
// 'https://www.google.com/search?q=programming+language'
url.toString();

En définissant la chaîne de requête via la propriété searchParams de l'objet URL, vous pouvez définir la chaîne de requête.

Dans ce cas, l'espace est converti en . Avant d'expliquer pourquoi cela se produit, testons-la avec une autre chaîne de requête pour voir comment elle gère les autres caractères spéciaux.

const url = new URL('https://www.google.com/search');
url.searchParams.set('q', 'what is the meaning of &?');
// 'https://www.google.com/search?q=what+is+the+meaning+of+%26%3F'
url.toString();

Les autres caractères spéciaux sont codés comme prévu.

Voyons maintenant pourquoi ces différences se produisent.

---

Codage

1. encodeURI

Les fonctions encodeURIX codent selon la RFC2396. Un URI n’est pas seulement un emplacement sur Internet ; il peut faire référence à n’importe quel type de ressource. C'est pourquoi on l'appelle URI (Uniform Resource Identifier) ​​plutôt qu'URL (Uniform Resource Locator).

---

2.URL

L'API URL code selon la RFC3986, qui est une spécification URI plus récente.

Si vous devez obtenir ce comportement avec encodeURI, référez-vous à ceci. - encodeURIComponent encodage pour RF3986).

L'URLSearchParams encode selon la règle de l'encodage en pourcentage. Selon la documentation, il remplace les espaces par ' '.

Bien que je n'aie pas trouvé la spécification dans RFC pour ce comportement, la documentation encodeURIComponent de MDN indique :

Pour application/x-www-form-urlencoded, les espaces doivent être remplacés par , on peut donc souhaiter faire suivre un remplacement encodeURIComponent() par un remplacement supplémentaire de with .

Cela explique pourquoi les espaces sont remplacés par ' ' dans URLSearchParams, car cela suit la norme application/x-www-form-urlencoded.

Vous avez peut-être remarqué que URL et URLSearchParams suivent des RFC différentes.

Voyons quelques exemples.

// 'https://www.google.com/search?q=programming%20language'
encodeURI('https://www.google.com/search?q=programming language')

Comme indiqué, l'URL n'encode pas les crochets et les deux-points, car ils font partie de l'adresse IPv6. Cependant, les deux points ne sont pas codés comme : même s'ils font partie de la chaîne de requête. C'est différent de la table de codage en pourcentage.

Cela signifie que vous devez encoder l'URL et la chaîne de requête séparément.

// 'https://www.google.com/search?q=what%20is%20the%20meaning%20of%20&?'
encodeURI('https://www.google.com/search?q=what is the meaning of &?')

Maintenant, l'URL et la chaîne de requête sont correctement codées.

---

Conclusion

Les fonctions encodeURI, encodeURIComponent, URL et URLSearchParams ont chacune un objectif différent et vous devez les utiliser en fonction de vos besoins spécifiques.

encodeURI : Encode un URI selon la RFC2396. Il ne code pas les caractères qui sont des parties valides d'un URI. Si vous devez encoder un URI selon la RFC3986, reportez-vous à cette documentation MDN.

encodeURIComponent : code un composant d'un URI selon la RFC2396, tel qu'un chemin, un fragment ou une chaîne de requête. Il inclut des caractères qui ne sont pas codés par encodeURI.

URL : code une URL Web conformément à la RFC3986.

URLSearchParams : Encodez les paramètres selon la norme application/x-www-form-urlencoded.

Si vous devez remplacer le signe (plus) par , vous pouvez le faire manuellement, comme indiqué ci-dessous :

const url = encodeURI('https://google.com/search');
const queryString = `?q=${encodeURIComponent('what is the meaning of &?')}`;
// 'https://google.com/search?q=what%20is%20the%20meaning%20of%20%26%3F';
url+queryString;

Lorsque vous travaillez avec du développement Web, des API Restful ou des URL Web, l'URL est un choix fiable. De plus, il suit la RFC3986, qui est plus récente que la RFC2396.

---

J'espère que vous avez trouvé cela utile.

Bon codage !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!