J'ai une URL de la sorte : http://monsite/R&d et dans mon htaccess je fais : RewriteRule ^([^/]*)$ /index.php?rch=$1
le problème est que lorsque je fais un $_GET["rch"] dans mon index.php, sa valeur est "R" au lieu de "R&d" ! Jusque là c'est normal sauf que j'aimerai pouvoir échapper l'esperluette (et commercial) dans l'htaccess !
J'ai trouvé cette piste : http://www.mediawiki.org/wiki/Apache_configuration/fr que j'ai adapté :
RewriteEngine On
RewriteMap ampescape int:ampescape
RewriteRule ^([^/]*)$ /index.php?rch=${ampescape:$1} [L]
Mais j'ai une erreur 500 de retournée !!! Grrrrrrrrrrrr !!!
Avez-vous une idée de commencer échapper les esperluette dans un .htaccess? Attention : le "&" restera en "&", je ne veux pas l'encoder en "%26" ou "%2526" pour que ça marche !
Merci d'avance !
Il ne faut pas utiliser d'esperluette dans l'url, parce qu'elle a un sens bien défini. C'est un peu comme si tu voulais appeler une fonction echo en php : t'as pas le droit. Ben là, c'est un peu pareil.
Tu peux (dois) utiliser urlencode() lors de la génération de tes URL. Le caractère correspondant est alors %26
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
Attention : le "&" restera en "&", je ne veux pas l'encoder en "%26"
Conclusion tu ne peux pas, c'est impossible, y'a pas moyen. Point. & est un caractère réservé, tu ne PEUX PAS l'utiliser pour autre chose que ce à quoi il est destiné.
Voici ce que dit la RFC 1738 :
Reserved:
Many URL schemes reserve certain characters for a special meaning:
their appearance in the scheme-specific part of the URL has a
designated semantics. If the character corresponding to an octet is
reserved in a scheme, the octet must be encoded. The characters ";",
"/", "?", ":", "@", "=" and "&" are the characters which may be
reserved for special meaning within a scheme. No other characters may
be reserved within a scheme.
(...)
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
Source : RFC 1738 §2.2 URL Character Encoding Issues
Conclusion : soit tu te conformes au standard qui est implémenté par tous les navigateurs de la planète sans exception, soit tu développes ton propre navigateur avec ses propres standards et tu t'arranges pour qu'il soit utilisé par les visiteurs de ton site. Sinon, tu utilises autre chose que & pour "R&D" dans ton url.
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
Merci pour ta réponse !
Honnêtement, je pense que c'est réellement possible car regarde un site comme celui-ci arrive à le faire :
Emploi R&d Donc doit-y avoir moyen de le faire : soit en modifiant l'htaccess ou par je ne sais quel autre moyen !
Vu le lien de mon premier poste, je pense qu'on peut le faire mais reste à savoir comment ...
Je crois que tu n'as pas bien compris comment fonctionne la réécriture d'url d'Apache. mod_rewrite d'Apache peut manipuler les url comme bon lui semble. Il a été codé en C et s'immisce dans le code d'Apache pour intercepter l'url avant qu'elle ne soit traitée comme telle.
mod_rewrite peut donc en faire à peu près ce qu'il veut. Je viens par exemple d'essayer ça :
RewriteEngine On
RewriteBase /
RewriteRule ^R&D test.php [L]
Ca marche. Si je tape http://localhost/R&D j'affiche bien la page test.php
Ce qu'il y a, c'est que PHP quant à lui n'est absolument pas capable de manipuler les url comme le fait mod_rewrite à un aussi bas niveau du code.
PHP se contente, lui, de respecter le standard qui dit que & est un séparateur d'arguments.
A partir de là, il existe deux solutions (je viens à l'instant de me souvenir de la seconde, que j'avias complètement oubliée, même hier soir).
1/ tu réécris ton URL comme tu veux, sans esperluette : après tout, l'utilisateur ne le verra pas, donc tu t'en fous un peu, c'est juste pour toi, histoire que ça marche. Par exemple :
D'après moi le serveur Web s'en fout un peu de la présence d'un "&", et ce n'est donc pas au niveau htaccess qu'il faut intervenir, mais PHP.
Pour la méthode GET (vue de PHP) le "&" a une signification particulière à laquelle tu ne pourras pas échapper: s'il s'agit de données il est impératif d'encoder les "&" ... et là tu n'as pas le choix !! (sinon, pour PHP, ce sont des paramètres d'URL)
Utiliser $_GET est donc à proscrire dans ce cas, mais PHP reste très flexible quant à l'analyse des URL :
je ne connais pas la structure de ton site et les URL que tu emploies, mais dans le cas que tu exposes un simple $_SERVER['QUERY_STRING'] devrait faire l'affaire (voir également 'REQUEST_URI'), en complément d'un htaccess qui se charge de la redirection vers index.php?...
C'est simple, mais ce n'est pas forcement très logique, et ça peut compliquer les choses.
Je n'y ai pas trop réfléchi mais sans doute est il possible de traiter ça côté htaccess. J'ai cependant bien peur que ça devienne une usine à gaz qui pose bien plus de problèmes que les solutions exposées ci dessus.
Très bien, merci à vous deux ! Je vais voir quelle solution est la meilleure. Pour régler mon problème j'avais en effet utilisé $_SERVER['QUERY_STRING'] mais je trouve ça crade de recréer ma variable $_GET à partir de $_SERVER['QUERY_STRING'] ! Ce serait tellement plus simple d'échapper les "&" dans le .htaccess ! Ils auraient pu y penser quand même :)
Bonne continuation les amis !!!
je trouve ça crade de recréer ma variable $_GET à partir de $_SERVER['QUERY_STRING']
Ce n'est pas totalement faut, et je disais moins même que ce n'était pas logique.
Comme nous l'avons déjà dit tu n'as pas le choix :
Si tu veux éviter toute bidouille ou micro pseudo bidouille : tu DOIS encoder le "&". La norme est ainsi faite, et tu as beau dire qu'"ils" auraient pu y penser, il n'y a pas le choix, il faut bien choisir un caractère !! (un autre aurait peut être été préférable, c'est vrai)
N'empêche qu'il me semble que l'idée que je donne soit la plus adaptée (mais comme d'hab je peut me tromper)
elle est généraliste, cad elle fonctionne quelque soit l'URL, et ne nécessite pas de ré écrire une ligne dans le htaccess à chaque fois que tu auras une url incluant un "&"
Une fois n'est pas coutume, mais je suis totalement en désaccord avec la seconde solution de Neige
