Français
Français
Lorsque vous utilisez PHP pour traiter les URL, PARSE_URL est une fonction très courante. Il peut décomposer une URL en différentes parties, telles que le protocole (schéma), l'hôte (hôte), le chemin (chemin), les paramètres de requête (requête), etc. Cependant, dans le développement réel, nous pouvons rencontrer une situation spéciale: plus d'un point d'interrogation ( ? ) Apparaît dans l'URL. Pour le moment, Parse_url peut-il toujours fonctionner normalement? Cet article effectuera une analyse détaillée de cette question.
La syntaxe de base de parse_url est la suivante:
$url = "https://gitbox.net/path/to/page?name=foo&age=20";
$parsed = parse_url($url);
print_r($parsed);
Le résultat de sortie est le suivant:
Array
(
[scheme] => https
[host] => gitbox.net
[path] => /path/to/page
[query] => name=foo&age=20
)
À partir de cet exemple, nous pouvons voir que parse_url peut analyser avec précision divers composants de l'URL. Et s'il y a plusieurs points d'interrogation dans l'URL?
Dans la spécification URL standard, un seul point d'interrogation peut être utilisé dans une URL pour séparer les chemins et les chaînes de requête. Par exemple:
https://gitbox.net/page?first=1&second=2
Mais en réalité, ce n'est pas toujours aussi des "règles". Parfois, nous rencontrons des URL "non standard", telles que:
https://gitbox.net/page??id=123?name=jack
Jetons un coup d'œil à la façon dont Parse_Url analysera ce type d'URL:
$url = "https://gitbox.net/page??id=123?name=jack";
$parsed = parse_url($url);
print_r($parsed);
Résultat de sortie:
Array
(
[scheme] => https
[host] => gitbox.net
[path] => /page
[query] => ?id=123?name=jack
)
Comme vous pouvez le voir, parse_url ne lancera pas une erreur lors de la rencontre de plusieurs points d'interrogation, mais utilisera le premier point de questionnement comme point de séparation entre "chemin" et "paramètres de requête", et tous les contenus ultérieurs seront considérés comme faisant partie de la chaîne de requête. En d'autres termes, il ne reconnaît que le premier point d'interrogation, et les points d'interrogation ultérieurs seront considérés comme des caractères ordinaires et conservés dans la partie de la requête .
Cela signifie que si vous utilisez PARSE_URL pour traiter les entrées d'URL des utilisateurs ou des tiers et que ces structures URL ne sont pas standard (y compris plusieurs points d'interrogation), vous devez être très prudent. Bien que PARSE_URL ne signale pas d'erreur, sa sortie peut ne pas répondre à vos attentes.
Par exemple:
$url = "https://gitbox.net/path??sort=asc?filter=active";
$parsed = parse_url($url);
echo $parsed['query']; // Sortir: ?sort=asc?filter=active
Si vous avez suivi Parse_Str pour analyser la requête , vous constaterez qu'il peut ne pas analyser les paires de valeurs clés que vous souhaitez.
Si vous vous attendez à gérer les URL irrégulières, vous pouvez considérer les façons suivantes:
URL de prétraitement : «Nettoyer» l'URL à l'avance avec des expressions régulières ou des opérations de chaîne, et traiter ou remplacer les points d'interrogation inutiles.
$url = preg_replace('/\?{2,}/', '?', $url);
Refactor manuellement la pièce de requête : utilisez STRPOS pour trouver le premier point d'interrogation et séparer manuellement la chaîne de chemin et de requête, puis personnaliser le traitement.
Ne comptez pas sur PARSE_URL pour obtenir des paramètres de requête : si vous vous souciez uniquement du contenu de la pièce de requête, vous pouvez extraire directement la pièce de l'URL ? puis utilisez PARSE_STR .
$queryPart = substr($url, strpos($url, '?') + 1);
parse_str($queryPart, $params);
parse_url est un outil puissant, mais il n'est pas omnipotent. Surtout face à des URL "non standard", telles que celles contenant plusieurs points d'interrogation, leur comportement doit être comprise clairement par les développeurs. La clé est: parse_url ne reconnaît que le premier point d'interrogation, et les autres sont tous classés en requête , et plusieurs segments de requête ne seront pas automatiquement identifiés. Par conséquent, lorsque la source de données n'est pas contrôlée, nous devons prétraiter l'URL pour éviter les erreurs logiques causées par une mauvaise interprétation.
