Page 1 of 2
Apstrophe help
Posted: Wed Jan 31, 2007 10:29 am
by spacebiscuit
Hi,
I havw written the following line of code:
Code: Select all
echo '<option value="index.php?menuitem=', urlencode('Valentines Day'), '">Valentines Day';
However I want to add apostrophies in the word "Valentines" so it is gramatically correct. When I do an error is detected as the parser thinks it has reached the end of the line. Is it possible?
Many thanks in advance.
Rob.
Posted: Wed Jan 31, 2007 10:52 am
by lornajane
If you want to use a quote inside a quoted string, you need to escape the string by adding a slash before the apostrophe.
Posted: Wed Jan 31, 2007 11:20 am
by louie35
aslo yu need to use . not ,
Code: Select all
echo '<option value="index.php?menuitem='. str_replace("_"," ","Valentines Day").'">Valentines Day';
//use str_replace for white spaces
Posted: Wed Jan 31, 2007 11:53 am
by feyd
Posted: Wed Jan 31, 2007 6:39 pm
by RobertGonzalez
louie35 wrote:aslo yu need to use . not ,
Code: Select all
echo '<option value="index.php?menuitem='. str_replace("_"," ","Valentines Day").'">Valentines Day';
//use str_replace for white spaces
No, the poster does not need to use
str_replace().
urlencode() will handle the space for him.
Posted: Wed Jan 31, 2007 8:04 pm
by Ollie Saunders
louie35 wrote:aslo yu need to use . not ,
Nope, read the manual on echo. Comma performs faster but generally isn't recommended because it isn't polymorphic with string assignments. I use comma when I know the code will only be used for output and will definitely never be stored.
Re: Apstrophe help
Posted: Wed Jan 31, 2007 8:16 pm
by da404lewzer
Code: Select all
echo '<option value="index.php?menuitem=' . urlencode('Valentine\'s Day') . '">Valentines Day</option>';
you should get into the habit of closing your option tags to ease xhtml1 compliancy...
Posted: Wed Jan 31, 2007 8:43 pm
by Kieran Huggins
or you could use base64_encode() and then base64_decode() on the other side to recreate the exact value...
double quotes are handy in cases like this as well:
Code: Select all
echo '<option value="index.php?menuitem=' . base64_encode("Valentine's Day") . '">Valentine\'s Day</option>';
Later:
Code: Select all
echo base64_decode($_POST['holiday']);
Posted: Wed Jan 31, 2007 10:59 pm
by da404lewzer
base64_encode():
/index.php?menuitem=VmFsZW50aW5lJ3MgRGF5
urlencode():
/index.php?menuitem=Valentine%27s+Day
rawurlencode():
/index.php?menuitem=Valentine%27s%20Day
Posted: Thu Feb 01, 2007 4:54 am
by Ollie Saunders
Kieran Huggins wrote:or you could use base64_encode() and then base64_decode() on the other side to recreate the exact value...
Why would you want to do that?
Posted: Thu Feb 01, 2007 9:02 am
by superdezign
For a legitimate reason to use a base64_* function? :-p
It's readable and not really error-prone.
Posted: Thu Feb 01, 2007 10:33 am
by Kieran Huggins
I just think it's more dense and less distracting than (raw)?url(en|de)code - Also you don't need to worry about ampersands messing up your url parsing.
The downside of base64* is that it's non-human-readable, but if I'm using a request to pass any amount of data to the server I'll typically just POST it.
urlencode is great for making 'tokens' - like url friendly article names, but even then I'm inclined to just remove the offending characters altogether (with a few custom substitutions):
http://domain.com/holidays/valentines_day instead of:
http://domain.com/holidays/Valentine%27s%20Day
But no token should ever need to be decoded, so it's not really an encoding so much as a 'leg up' on a transformation.
My rule is basically this: when passing things like select options, I base64_encode them and call it a day. Do the urlencode functions handle things like newlines? I've just never tried...
Posted: Thu Feb 01, 2007 6:14 pm
by Ollie Saunders
Also you don't need to worry about ampersands messing up your url parsing.
url(en|de)code deals with that.
The downside of base64* is that it's non-human-readable
Yes that is a downside. Makes debugging more labour intensive
but even then I'm inclined to just remove the offending characters altogether (with a few custom substitutions)
Oh yeah definitely, but that's not always possible or worth doing.
My rule is basically this: when passing things like select options, I base64_encode them and call it a day.
What for?
Do the urlencode functions handle things like newlines? I've just never tried...
They wouldn't be very good if they didn't handle just about anything you could possibly throw at them.
Posted: Thu Feb 01, 2007 6:34 pm
by Kieran Huggins
Some not-so-obvious downsides to url(en|de)code:
man page wrote:Note: Be careful about variables that may match HTML entities. Things like &, © and £ are parsed by the browser and the actual entity is used instead of the desired variable name. This is an obvious hassle that the W3C has been telling people about for years. The reference is here: ยป
http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2. PHP supports changing the argument separator to the W3C-suggested semi-colon through the arg_separator .ini directive. Unfortunately most user agents do not send form data in this semi-colon separated format. A more portable way around this is to use & instead of & as the separator. You don't need to change PHP's arg_separator for this. Leave it as &, but simply encode your URLs using htmlentities() or htmlspecialchars().
man page wrote:Apache's mod_rewrite and mod_proxy are unable to handle urlencoded URLs properly -
http://issues.apache.org/bugzilla/show_bug.cgi?id=34602
If you need to use any of these modules and handle paths that contain %2F or %3A (and few other encoded special url characters), you'll have use a different encoding scheme.
man page wrote:In JavaScript when you try to encode utf-8 data with escape function you will get some strange encoded string which you wont be able to decode with php url(de)encode funtions.
man page wrote:Not all browsers perform the same encodeing.
man page wrote:microsoft uses an different table for encode string when sending data...
base64_(en|de)code doesn't seem to suffer from nearly as many caveats, and the only thing you lose is URL readability, which (IMO) you shouldn't be using it for anyway. Thus, I save my Advil money and debugging time and treat myself to an overpriced coffee once in a while

Posted: Thu Feb 01, 2007 6:39 pm
by Ollie Saunders
OK I had no idea there were so many portability problems surrounding URL encoded strings. That's quite shocking actually.