Analyser les problèmes causés par les caractères spéciaux dans les URL PHP (+,\,=)

Recommandé : "Tutoriel vidéo PHP"

Problèmes causés par les caractères spéciaux dans l'URL en PHP (+,,=)

Préface , en train de travailler sur un certain canal, une erreur de vérification de signature a été découverte. Cependant, à cette époque, les performances de vérification des signatures étaient incohérentes aux deux endroits avec le même ensemble de méthodes de traitement. Je pensais que c'était parce que les méthodes de requête aux deux endroits étaient différentes. L'une était la méthode get et l'autre était naturellement la méthode get. méthode de publication. Bien sûr, le problème doit être résolu.

GET et POST

Méthode de requête GET, étant donné que les paramètres sont placés dans l'URL, il peut y avoir des problèmes de politique du côté du navigateur lors de leur transmission du code Urlen. paramètres. Par conséquent, lorsque vous obtenez les paramètres côté serveur, il se peut qu’il ne s’agisse pas des données d’origine. Par conséquent, lors de la demande de données via GET, si aucun traitement n'est effectué, des problèmes peuvent survenir lors de la vérification de la signature. La possibilité ici est que le caractère spécial + ne soit pas inclus après le traitement base64 et que + soit une chaîne vide sans aucun traitement après la méthode GET.

La méthode de requête POST place les paramètres dans le corps de la requête. Lors du processus de transfert http, il n'y aura pas de traitement des paramètres en raison de certains problèmes stratégiques du navigateur. Par conséquent, il n'y aura aucun problème lors de la vérification de la signature des paramètres via des requêtes POST, et la vérification de la signature peut être effectuée sans problème. Cependant, nous n'avons aucun moyen de demander au fournisseur de chaîne de transformer la demande d'obtention en demande de publication, nous ne pouvons donc trouver un moyen que nous-mêmes.

urlencode et urldecode

urlencode:
(PHP 4, PHP 5, PHP 7)
urlencode — 编码 URL 字符串
string urlencode ( string $str )

Cette fonction facilite l'encodage d'une chaîne et son utilisation dans la partie requête de l'URL, elle facilite également le passage de variables à la page suivante .

return

Renvoie une chaîne dans laquelle tous les caractères non alphanumériques sauf -_ seront remplacés par un signe de pourcentage (%) suivi de deux chiffres hexadécimaux, et les espaces sont codés par un signe plus (+). Cet encodage est le même que l'encodage des données POST du formulaire WWW, et le même que l'encodage du type de média de application/x-www-form-urlencoded

urldecode:
(PHP 4, PHP 5, PHP 7)

urldecode — Décode une chaîne d'URL encodée

string urldecode ( string $str )

Décoder n'importe quel %## dans la chaîne codée donnée. Le signe plus (« + ») est décodé en un caractère espace.

Renvoie la chaîne décodée.

Il semblerait qu'on ait vu le jour, la « manière parfaite » de traiter le +, une corde qui va se transformer en espace. Autrement dit, codez urlen la chaîne de signature pour la chiffrer. Ensuite, vérifiez avec plaisir, fxxk, faux. Si vous ne réussissez toujours pas, donnez-vous une gifle. Après le cryptage base64, la chaîne de remplissage = apparaîtra, ce qui est très pénible. J'ai donc pensé à une solution temporaire.

urlencode(substr($str,0,strlen($sign)-2)).substr($sign,strlen($sign)-2)

A cette époque, considérant qu'il y avait au plus deux == en base64, le traitement de l'urlencode n'était pas effectué sur les deux derniers. Cela peut fondamentalement être géré, mais il peut y avoir un problème, c'est-à-dire que cela ne fonctionnera pas si + apparaît dans les deux derniers chiffres, ce plan ne peut pas être convaincu et annulé. Et un problème également découvert au cours de ce processus est que la chaîne de signature transmise peut avoir été traitée par urlencode. C'est encore un petit problème. Effectuez d'abord le traitement de décodage d'url, car le décodage ne provoquera pas de malentendus.

A cette époque, un ami a proposé une solution, c'est-à-dire qu'il ne suffirait-il pas de simplement remplacer le signe + ? En effet, c'est une façon. Mais je pense que cette méthode est très frustrante. Que se passe-t-il si l'algorithme de cryptage change ou si d'autres caractères spéciaux sont ajoutés à l'avenir, tels que @#￥%...&**( etc., nous ne pouvons pas tous faire correspondre et remplacer. Donc, Je suis d'accord Solution temporaire, mais je continue de penser à

rawurlencode et rawurldecode

rawurlencode:
(PHP 4, PHP 5, PHP 7)

rawurlencode — Encoder les URL selon la RFC 3986

string rawurlencode ( string $str )

Encodez les caractères spécifiés selon » RFC 3986

rawurldecode:
(PHP 4, PHP 5, PHP 7)

rawurldecode — Décodez la chaîne URL codée

string rawurldecode ( string $str )

et renvoie une chaîne dans laquelle un signe de pourcentage (%) est suivi de deux caractères. Les nombres hexadécimaux seront remplacés par des caractères littéraux. Une nouvelle aube est apparue, comprenant le rawurldecode et le remplaçant par des caractères littéraux. Par conséquent, la solution est prête 🎜>À première vue, cela semble gonflé ou pourquoi devez-vous y faire face. d'une manière si détournée ? Quant à savoir pourquoi, veuillez lire les vantardises ci-dessus

Postscript

En tant que programmeurs, nous devons avoir deux préparations, l'une est une solution temporaire, ce qui peut résoudre rapidement le problème actuel et le restaurer à la normale, mais à long terme, nous devons avoir une solution stable et fiable. Vous continuez à essayer php.net .

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!