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
Related
I'm using PHP5 and OCI 8 with Oracle 11g.
When I fetch a row using oci_fetch_all, the whole result is converted as STRING even for the NUMBER columns and even if I use Oracle's TO_NUMBER in the query.
What I'm trying to do is simple: the javascript calls the PHP script through an Ajax request. The script just fetch some NUMBER data and encode them into JSON. I want the data to be encoded as integer, so the javascript can do math stuff on it (add, divide,..etc) without any conversion.
I am pretty sure that the problem comes from OCI and not JSON encoding because when I VAR_DUMP the result of oci_fetch_all, I can clearly see double quotes on every result:
{
"COLUMN1":"12",
"COLUMN2":"52"
}
I want the result to look like this:
{
"COLUMN1":12,
"COLUMN2":52
}
I tried to:
Change the flag of oci_fetch_all (OCI_FETCHSTATEMENT_BY_ROW, OCI_FETCHSTATEMENT_BY_COLUMN...)
Use oci_fetch_array instead of oci_fetch_all
Remove the UTF8 encoding on the connexion to oracle (I know, its stupid)
The strange thing is that I can't find any thing on the internet about this problem... It's like nobody faced the same issue. Maybe i'm doing something wrong...
Thanks in advance
You can use an extra option in json_encode:
json_encode($rows, JSON_NUMERIC_CHECK);
However this option requires a PHP version of 5.3.3 or higher (thus its ok for you).
All database extensions in PHP work like this, there's nothing you can do about it.
You'll have to manually type-cast the database results.
I'm very new to PHP but have a good understanding of C,
When I want to access some post data on an API i'm creating in PHP I use:
$_POST['date_set']
to fetch a value being passed for date - This all works perfectly, however I read I should be fetching it like this:
$date_set = trim(urldecode($_POST['date_set']));
This always returns a 00:00:00 value for the date after it's stored in my DB.
When I access directly using $_POST['date_set'] I get whatever value was posted, for example: 2013-08-28 10:31:03
Can someone tell me what I'm messing up?
You should try it like,
$date_set = $_POST['date_set'].explode(' ');//('2013-08-28 10:31:03').explode(' ')
echo $date_set[1];
or
echo date('H:i:s',strtotime($_POST['date_set'])));
//echo date('H:i:s',strtotime('2013-08-28 10:31:03'));
If you are very new in php the Read date()
You only run urldecode over data is URL encoded. PHP will have decoded it before populating $_POST, so you certainly shouldn't be using that. (You might have to if you are dealing with double-encoded data, but the right solution there should be to not double encode the data).
trim removes leading and trailing white-space. It is useful if you have a free form input in which rogue spaces might be typed. You will need to do further sanity checking afterwards.
urldecode — Decodes URL-encoded string
Description
string urldecode ( string $str )
Decodes any %## encoding in the given string. Plus symbols ('+') are decoded to a space character.
urldecode: is used only for GET requests. you should be fine using $_POST['date_set'] only.
http://php.net/manual/en/function.urldecode.php
You'd better do this way
if(isset($_POST['date_set'])){
$date_set = $_POST['date_set'];
}
then you can use $date_set how you want.
If you still get 00:00:00 for $date_set, the problem is coming from the code which provide you the $_POST value.
I am trying to parse the json output from
http://www.nyc.gov/portal/apps/311_contentapi/services/all.json
And my php json_decode returns a NULL
I am not sure where the issue is, I tried running a small subset of the data through JSONLint and it validated the json.
Any Ideas?
The error is in this section:
{
"id":"2002-12-05-22-24-56_000010083df0188b4001eb56",
"service_name":"Outdoor Electric System Complaint",
"expiration":"2099-12-31T00:00:00Z",
"brief_description":"Report faulty Con Edison equipment, including dangling or corroded power lines or "hot spots.""
}
See where it says "hot spots." in an already quoted string. Those "'s should've been escaped. Since you don't have access to edit the JSON perhaps you could do a search for "hot spots."" and replace it with \"hot spots.\"" like str_replace('"hot spots.""', '\\"hot spots.\\""\, $str); for as long as that's in there. Of course that only helps if this is a one time thing. If the site continues to make errors in their JSON output you'll have to come up with something more complex.
What I did to identify the errors in the JSON ...
Since faulty quoting is the first thing to look for, I downloaded the JSON to a text file, opened in a text editor (I used vim but any full featured editor would do), ran a search and replace that removed all characters except double-quote and looked at the result. It was clear that correct lines should have 4 double-quotes so I simply searched for 5 double-quotes together and found the first bad line. I noted the line number and then undid the search and replace to get the original file back and looked at that line. This gives you what you need to get the developers of the API to fix the JSON.
Writing code to automatically fix the bad JSON before giving it to json_decode() would be quite a bit harder but doable using techniques like those in another answer.
According to the PHP manual:
In the event of a failure to decode, json_last_error() can be used to determine the exact nature of the error.
Try calling it to see where the error is.
In my particular case, I'm getting this error after doing an ExpressionEngine update from 1.x to 2.x. There is a table that manages site preferences, and the data for each field is a serialized PHP array. After the update, any serialized array instead just says czowOiIiOw==. Googling this string brings up other non-ExpressionEngine-related site forums where end users are reporting seeing this string while being unable to login.
Does anyone have any idea what might be causing this, or have you seen anything like this before?
It's an encoding of a serialization of an empty string.
>>> 'czowOiIiOw=='.decode('base64')
's:0:"";'
Somehow your preferences got wiped.
that is base64 encoded. it's :
s:0:"";
It's a base64-encoded version of s:0:"", which is a serialized PHP empty string.
Decoding it as base64 it becomes:
s:0:"";
As you can see if you execute the following line, it is a serialized empty string:
echo serialize(""); // Outputs s:0:"";
echo base64_encode(serialize("")); // Outputs czowOiIiOw==
For further information on the serialization spec, see this generous commenter's work, specifically Strings:
Anatomy of a serialize()'ed value:
...
String
s:size:value;
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?