kylewolfe — 2013-02-14T21:44:12-05:00 — #1
I'mmm having problems decoding when I add in the ENT_QUOTES portion...
unserialize(htmlspecialchars_decode($this->getRequest()->getParam("details"))); //first line is posted to new script
I've trid the decode with the ENT_QUOTES argument, as well as messed with htmlentities with no avail. I don't think it'll be necessary to provide the data within the array, just know that it has apostrophes
cpradio — 2013-02-15T05:50:05-05:00 — #2
Why do you need either of those? I would assume urlencode would be sufficient enough.
another alternative is using base64_encode and passing the encoded value
kylewolfe — 2013-02-15T09:41:48-05:00 — #3
Hmm, I might have been testing with an extra ' at the end from my url :D. Either way I went with base64 + json_encode, thanks for the idea!
lemon_juice — 2013-02-15T09:50:38-05:00 — #4
The thing is if you use ENT_QUOTES for htmlspecialchars() you have to use ENT_QUOTES for htmlspecialchars_decode():
And I think cpradio is right that urlencode() is probably more suited for urls - if you add serialized data to a url then most probably you pass it in the query string, in which case htmlspecialchars is not enough and the data will become corrupt on certain characters (this also applies if you use mod_rewrite so as to make nicer urls). htmlspecialchars is just a general escaping function for any data you put into html attributes and it does not cover escaping for urls.
Edit: even if you use base64_encode you need to escape the string with urlencode before putting it in the url, because base64-encoded data may contain special characters like +, / and = - you will then not be able to properly receive the data using $GET. This eventually makes base64encode not necessary for passing data via urls unless you want to add some visual obfuscation :).
cpradio — 2013-02-15T10:22:24-05:00 — #5
+1 :tup: I've run into that exact issue before. You definitely still want to use urlencode and urldecode when passing the base64 string around.
kylewolfe — 2013-02-15T10:35:34-05:00 — #6
I said I tried that in the decode as well
Those are acceptable in a URL, and my GET is handling them correctly due to Zends mod rewrite
lemon_juice — 2013-02-15T11:01:01-05:00 — #7
Oh, I didn't notice... But can you post some sample data and code that illustrates this doesn't work? This is weird because I have tested this with data containing apostrophes and htmlspecialchars_decode works as expected.