serialize data is
a:8:{s:10:"First_Name";s:6:"harish";s:9:"Last_Name";s:5:"verma";
s:5:"Email";s:16:"harish#facebook.com";s:7:"Address";s:6:"jaipur";s:4:"City";s:6:"Jaipur";s:5:"State";
s:9:"Rajasthan";s:12:"Country_Name";s:5:"India";s:7:"Cell_No";s:10:"8787878787";}
it return true when we change Email to harish#gmail.com .... please help and thanks in advance.
If you notice in the serialized data you have this section defining the email address
s:16:"harish#facebook.com";
Thats says this field is a string of 16 characters. The string in the field is NOT 16 characters its 19 characters
So I guess you are manually fiddling with the data after is has been properly serialize()'d
If you are going to manually mess with the serialized data you also have to make it all add up. So either stop manually editing it and re serialize() the data properly OR remember to also change the size parameter data to match your edits.
Related
I have a serialized object stored in a mysql database in a column of type text saved via php.
If I double click the field in PHPMyAdmin to edit the value of the field inline, and then save the edit by clicking away from the edit box, the serialized data in the field is rendered corrupt somehow.
I get the following PHP error after doing this:
Notice: unserialize(): Error at offset 913 of 1951 bytes in /path/to/file.php on line 46
I am not even changing any of the data, as I am only clicking in to copy the data to the clipboard so it's not as though I'm introducing anything weird, or making an error with the syntax etc. I thought maybe some whitespace is getting added or some wierd character(s).
Is there a solution to this?
According to this question, in order to avoid errors you can try to base64 the output or serialize() before inserting it into the database:
$toDatabse = base64_encode(serialize($data)); // Save to database
$fromDatabase = unserialize(base64_decode($data)); //Getting Save Format
There is a bug in phpmyadmin that saves the '\n' of a serialized php string as line breaks. PHP serialized strings must not contain line breaks! If you want to safely modify it directly from phpmyadmin, make sure to replace the line breaks with '\n' string, this can easily be done from any text editor.
I'm writing PHP code that uses a database. To do so, I use an array as a hash-map.
Every time content is added or removed from my DB, I save it to file.
I'm forced by my DB structure to use this method and can't use mysql or any other standard DB (School project, so structure stays as is).
I built two functions:
function saveDB($db){
$json_db = json_encode($db);
file_put_contents("wordsDB.json", $json_db);
} // saveDB
function loadDB(){
$json_db = file_get_contents("wordsDB.json");
return json_decode($json_db, true);
} // loadDB
When echo-ing the string I get after the encoding or after loading from file, I get a valid json (Tested it on a json viewer) Whenever I try to decode the string using json_decode(), I get null (Tested it with var_dump()).
The json string itself is very long (~200,000 characters, and that's just for testing).
I tried the following:
Replacing single/double-quotes with double/single-quotes (Without any backslashes, with one backslash and three backslashes. And any combination I could think of with a different number of backslashes in the original and replaced string), both manually and using str_replace().
Adding quotes before and after the json string.
Changing the page's encoding.
Decoding without saving to file (Right after encoding).
Checked for slashes and backslashes. None to be found.
Tried addslashes().
Tried using various "Escape String" variants.
json_last_error() doesn't work. I get no error number (Get null, not 0).
It's not my server, so I'm not sure what PHP version is used, and I can't upgrade/downgrade/install anything.
I believe the size has something to do with it, because small strings seem to work fine.
Thanks Everybody :)
In your JSON file change null to "null" and it will solve the problem.
Check if your file is UTF8 encoded. json_decode works with UTF8 encoded data only.
EDIT:
After I saw uploaded JSON data, I did some digging and found that there are 'null' key. Search for:
"exceeding":{"S01E01.html":{"2217":1}},null:{"S01E01.html":
Change that null to be valid property name and json_decode will do the job.
I had a similar problem last week. my json was valid according to jsonlint.com.
My json string contained a # and a & and those two made json_decode fail and return null.
by using var_dump(json_decode($myvar)) which stops right where it fails I managed to figure out where the problem was coming from.
I suggest var_dumping and using find dunction to look for these king of characters.
Just on the off chance.. and more for anyone hitting this thread rather than the OP's issue...I missed the following, someone had htmlentities($json) way above me in the call stack. Just ensure you haven't been bitten by the same and check the html source.
Kickself #124
my serialized data looks like this
a:6:{i:0;s:12:"Early humans";i:1;s:32:"Apes And Hominids Dart's Find";i:2;s:36:"The hunter gatherers of South Africa";i:3;s:25:"Early Humans The Eve Gene";i:4;s:50:"Australopithecines, Homo ergaster and Homo sapiens";i:5;s:21:"Landscapes of history";}
When i try and unserialize, it turns out to be empty.
my code:
$urlnames = unserialize($row['url_name']);
foreach($urlnames as $names){
echo $name;
}
What am I doing wrong?
Thanks
The serialized string is wrong. There should be one more character in the "Dart's find" string -- I don't know why one is missing, but adding one will make it work fine.
See for yourself.
On index 1 you have only 31 characters that's why it isn't working.
Did you get your serialized string form the db?
If you get it from there, than your backslash is missing. That's your 32th character.
more info about backslashes and databases check google/yahoo/bing ...
I have been struggling with this for three days now and this is what i have got and i cannot understand why i am seeing this behavior.
my problem is that i have a MySql spanish db with char set and collation defined as utf8_general_ci. when i query the data base in delete.php like this "DELETE FROM countryNames WHERE country = '$name'"
the specified row doesnot get deleted. i am setting the variable $name in delete.php through a post variable $name=$_post['data'] . mostly $name gets the value in spanish characters e.g español, México etc. the delete.php file gets called from main.php.if i send a post message from main.php $.post("delete.php", {data:filename}); , the query doesnot deletes the entry (although the 'filename' string is in utf8) but if i create a form and then post my data variable in main.php, the query works!! the big question to me is why do i have to submit a form for the query to work? what im seeing is my database rejects the value if it comes from a jquery post call but accepts it when its from a submitted form. (i make no code change for the query to work. just post the value by submiting the form)
First of all, to see what charset ìs used for requests, install something like Firebug and check the 'Content-Type' header of your request/response. It will look something like 'application/json; charset=...'. This should be charset=utf-8 in your case.
My guess why it worked when posting a form is probably because of x-www-form-urlencoded - non-alphanumeric characters are additionally encoded on the client side and again decoded on the server, that's the difference to posting the data directly.
This means that somewhere there is a wrong encoding at work. PHP treats your strings agnostic to its encoding by default, so I would tend to rule it out as the source of the error. jQuery.post also uses UTF-8 by default... so my suspect is the filename variable. Are you sure it is in UTF-8? Where and how do you retrieve it?
You should probably also ensure that the actual HTML page is also sent as UTF-8 and not, let's say iso-8859-1. Have a look at this article for a thorough explanation on how to get it right.
guys this was a Mac problem!! i just tested it on windows as my server and now everything works fine. So beware when u r using Mac as a server with MySql having UTF8 as charset and collation. I guess the Mac stores the folder and file name in some different encoding and not UTF-8.
You answer might be here: How to set encoding in .getJSON JQuery
As it says there, use $.ajax instead of $.post and you can set encoding.
OR, as it says in the 2nd answer use $.ajaxSetup to set the encoding accordingly.
Use .serialize() ! I think it will work. More info: http://api.jquery.com/serialize/
My previous question and this question both are related a bit. please have a look at my previous question I did not found any other way to unserialize the data so coming with the string operation
I am able to get the whole content from file but not able to get the specific string from this content.
I want to search a specific string from these content but function stop working when the reach at first special character in the string. If I am searching something found before the special character the works properly.
String operation function of PHP not working properly when the encounter first special character in the string and stop processing immediately, Hence they does not give me the correct output.
Originally they looks like (^#)
:"Mage_Core_Model_Message_Collection":2:{s:12:"^#*^#_messages";a:0:{}s:20:"^#*^#_lastAddedMessage";N;}
but when I did echo they are display as ?
Here is the code what I tried
$file='/var/www/html/products/var/session/sess_ciktos8icvk11grtpkj3u610o3';
$contents=file_get_contents($file);
$contents=htmlspecialchars($contents);
//$contents=htmlentities($contents);
echo $contents;
$restData=strstr($contents,'"id";s:4:"');
echo $restData;
$id=substr($restData,0,strpos($restData,'"'));
echo $id;
I changed the default_charset to iso-8859-1 and also utf-8 but not working with both
Please let me know How I can resolve this.
Thanks.
These characters that you see as ^# are actually null bytes. They don't have any proper display, neither they are meant to be displayed - it's an internal representation of protected properties in the engine. You're not supposed to mess with them.
As for resolving, it'd be nice to know what kind of resolution you seek - what result are you trying to achieve?