I have a web app where I first store JSON data in a cookie, then save to the database every x seconds. It just opens a connection to the server, and the server reads the cookie. It doesn't actually send anything via POST or GET.
While I save to the cookie, my data is formatted fine. However, when I work with it in PHP then setcookie a new json_encoded array, it replaces spaces with + symbols, and then these show up in my web app. I can't find any way to disable encoding of strings for json_encode, nor a JS way of parsing those plus symbols out (using jQuery.parseJSON; stringify's parse didn't work either)... Does anyone have any idea :S?
From the fine manual:
Note that the value portion of the cookie will automatically be urlencoded when you send the cookie, and when it is received, it is automatically decoded and assigned to a variable by the same name as the cookie name. If you don't want this, you can use setrawcookie() instead if you are using PHP 5.
But I think you still want the cookie URL encoded, you just want %20 for spaces instead of +. However, urlencode:
[...] for historical reasons, spaces are encoded as plus (+) signs
You could try using rawurlencode to encode it yourself:
Returns a string in which all non-alphanumeric characters except -_.~ have been replaced with a percent (%) sign followed by two hex digits. This is the encoding described in RFC 3986 [...]
And then setrawcookie to set the cookie. Unfortunately, none of decodeURI, decodeURIComponent, or even the deprecated unescape JavaScript functions will convert a + back to a space; so, you're probably stuck forcing everyone to make sense the hard way.
Related
I'm working on an Android app which sends some hashes to the server. Of course, the hashes often contain special characters like + = /. I found out that my PHP script is automatically changing the + symbol with a blank space, which somehow breaches in my own security mechanism.
I could've simply replaced the blank space with the + sign using the str_replace() function, but I'm worried if there can be more circumstances like this where PHP changes some special characters with some other characters. Also, It's not the ethical way.
1) Is it only about the + symbol or there can be other occurrences too?
2) What is the correct way to get the raw (unformatted) string?
As mentioned in my comment this is an encoding issue and should be fixed in the Request (Android app) rather than the server. Check this answer for a Java example.
To your specific questions:
There are a number of "control characters" that NEED to be encoded because they have a special meaning: + ? &
I don't think it's possible to get the original string in PHP, as PHP likely never sees it. The webserver will likely URL-decode the params before passing it to PHP, as defined in URL/HTTP.
I have a cookie which I am setting based on data in a field in Drupal. When I write the cookie using PHP the extended ASCII characters are shown as hex-codes (e.g. %7E) but if I write a similar cookie with JavaScript then the extended ASCII characters are show in the cookie as single characters (e.g. ~ ).
This is the string I want in my cookie.
Section1~email,email.calendar,calendar.wordpresssml,wordpress.moodlesml,moodle.maharasml,mahara.gdrive,gdrive.eportfolio,eportfolioblogs.wiki,wiki.youtube,email.feature,feature|Section2~reader,reader|
If I use
setcookie("p", "Section1~email,email.calendar,calendar.wordpresssml,wordpress.moodlesml,moodle.maharasml,mahara.gdrive,gdrive.eportfolio,eportfolioblogs.wiki,wiki.youtube,email.feature,feature|Section2~reader,reader|", $expire);
I get Section1%7Eemail%2Cemail.calendar%2Ccalendar.wordpresssml%2Cwordpress.moodlesml%2Cmoodle.maharasml%2Cmahara.gdrive%2Cgdrive.eportfolio%2Ceportfolioblogs.wiki%2Cwiki.youtube%2Cemail.feature%2Cfeature%7CSection2%7Ereader%2Creader%7C
rather than the string I want. If I write the cookie using JavaScript it works fine. I know this is an encoding issue but I would really like PHP to write the cookie using the full set of Extended ASCII characters.
Why is this a problem? You have to remember that this will appear in the Set-Cookie HTTP header and by not encoding it you will always have to remember what the special characters are and avoid using them. With encoding, you don't have to worry about that.
With PHP, when you do $_COOKIE['p'] it will appear as you originally intended. If you want to extract it in Javascript using document.cookie or something, then you can use decodeURIComponent(cookieValue).
I let users write and then post what they have written to my MYSQL database, using PHP. I have been sending the strings as URLs and then $_GET['string'] in the php and then putting them in the database. I always have to take care of the spaces in the string by replacing them with %20. And then I had to replace all kinds of different characters on top of that in order for the URLs to work. This is a losing battle and the users expect their strings to be saved but if they contain a character I have not thought of, this will not be the case. I have even tried sending along the strings as NSData in a POST but that did not seem to save the strings either.
How can I be sure the users' strings will save, no matter what crazy characters they type?
Thanks,
R
Encode your data using NSUTF8StringEncoding before sending it to the server, and always use POST to send data to the server instead of GET. Also, it's a good idea to stop using ASCII altogether and to replace it with Unicode wherever you use strings. UTF-8 is a very convenient and compact Unicode encoding.
I'm not much of a PHP expert. I'm encoding a URL with base64_encode.
I get quite a long encoded string with a lot of weird characters exactly as I want it to be.
Is there a way to trim this long line of characters to let's say 10 or 15 chars, so I can decode it later again?
I know there is trim() but that does not exactly what I want. I want a long encoded string to be rather short and later I want to decode it again.
Any ideas?
It's not possible to "shorten" any string without losing some data.
If you want to physically shorten an encoded string (with the end result being only part of that string), apply substr() but not on the encoded version: You need to decode it first, then re-encode the shortened version.
Another option is to compress a string. This may shorten it somewhat: Look into gzcompress(). Your mileage may vary, though: the compression rate will depend on what kind of data you have. With small input strings, the result can even be larger than the original.
If you want to reuse a variable in a multi-page process, and don't want to transport it through a link or a form, consider generating a short random key, and storing the data in the user's session:
$_SESSION[$randomKey] = "lllloooooooooooong data here";
You could pass on the random key, and always access the "long" data using $_SESSION[$randomKey]. You need to have a session initialized for this.
I have a website that uses the facebook, twitter, delicious share links. They contain a a url encoded url of the website that you wish to share. The problem is I then want to send the facebook/twitter/delicious url through a php redirect page.
Will it work to encode a url within an encoded url? Will there be side effects?
To simplify my question:
www.website.com/redirect.php?url=" URLENCODED (http://www.facbook.com/sharer.php?t='URLENCODED(title)'&u='URLENCODED(http://www.hotel.com)')
You can encode a string multiple times with the percent encoding and get the original value by decoding it the same amount of times:
$str = implode(range("\x00", "\xFF"));
var_dump($str === urldecode(urldecode(urldecode(urlencode(urlencode(urlencode($str)))))));
Here the value of $str is encoded three times and then decoded three times. The output of that repeated encoding and decoding is identical to the value of $str.
So try this:
'http://example.com/redirect.php?url='.urlencode('http://www.facbook.com/sharer.php?t='.urlencode('title').'&u='.urlencode('http://www.hotel.com'))
You should be able to recursively encode the URL as many times as you want. If you encode a character like / repeatedly you will get:
0: /
1: %3F
2: %%3F
3: %%%%3F
etc.
It's all right to add a second layer of URLEncoding. The idea of URLEncoding is to prevent the server from misinterpreting any special characters that may be present in a text string. However, the receiving script must expect an extra layer of urlencode(), and act accordingly.
Or if you know the string has been urlencoded, couldn't you simply pass it along as-is? No further urlencoding is necessary.
Or just urldecode the title and URL, then urlencode the whole string.
As mentioned earlier you can encode urls as much as you like but you should know the more times you encode url data the more it'll increase in length may be up two twice in length. which will be annoying for users if it is too long. also there may be a limitation on url length on some browsers.
Also on the server side there will be an overhead encoding and decoding the data.
In short you should really be sure you need it before encoding/decoding multiple times.