To view the terms under which this email is distributed, please go to 
http://disclaimer.leedsmet.ac.uk/email.htm



> -----Original Message-----
> From: Stuart Felenstein [mailto:[EMAIL PROTECTED] 
> Sent: 09 December 2004 13:38
> 
> --- "Ford, Mike" <[EMAIL PROTECTED]> wrote:
> 
> > Are you seeing the URL-encoded version *only* in
> > your browser's
> > Address/Location bar?  If so, that's perfectly
> > normal and nothing to worry
> > about -- it should be automatically decoded by the
> > Web server before being
> > passed to PHP.
> 
> > 
> > If you're seeing the encoded version actually in
> > your PHP script, that
> > sounds like a major problem, possibly indicating a
> > missing urldecode() or
> > extraneous urlencode() -- in which case, please post
> > a more detailed
> > analysis of your problem, examples of the unwanted
> > behaviour, and the
> > relevant portions of script.
> > 
> I have no idea about what it means to see the encoded
> version in my script. I have only one urldecode in the
> script:
> 
> <a href="SearchJobDetails.php?JobID=<?php echo 
> urldecode($row_rsVJ['JobID']);?>">

I actually doubt whether you even need this urldecode() -- but it depends
where that value is coming from.

> Further, I was assuming I should add the urldecode to
> the query string.

I don't quite understand this -- if you mean the query string supplied to
your script and manifesting in your $_GET array, then no, very unlikely,
since this should have been taken care of by the Web server before it gets
anywhere near PHP.  If you're referring to echoing out URLs with query
strings on them, then that is one of the few instances where urlENcode()
might be necessary, but definitely not urlDEcode().

> Lastly, I wasn't concerned about the hex code, but I
> just made some reconnections of scripts.  Users can
> save their search parameters.  I am saving the query
> string.  Now I had this set up before and the way it
> "was" working , is when the user wanted to view or
> edit their saved searches, the search page would come
> back with all the parameters filled in including
> shaded parameters in things like mult select lists and
> menu dropdowns.  It's not working that way now , so my
> first suspicion is perhaps the hex is effecting it.

All I can say to this is to re-iterate the point that your Web server should
be decoding those %xx values before your script ever gets to see them.  You
*may* have to urlencode() values you write out that might one day form part
of a clickable link -- but, because of the previous sentence, you should not
yourself need to do the compensating urldecode() in the target script.

Once again, this sounds like a situation where you need to be echoing out
everything and anything of even the slightest relevance at the crucial spots
of your script -- in the debugging phase, my scripts often have a bunch of
debugging echoes every few lines, and some sections even end up with more
temporary echoes than actual script!  It's tedious wading your way through
the screenfuls of output, but can be exceedingly illuminating of an elusive
problem.

Cheers!

Mike

---------------------------------------------------------------------
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services, JG125, James
Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS,
LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730      Fax:  +44 113 283 3211

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to