The JSON format on which it rests guarantees maximum interoperability while ensuring good readability. The implementation done in the JsonDumper class operates all potentialities of the representation while providing maximum latitude to the developer to exploit its ability as desired, both in term of exposure of internal class mechanism for specialization and in terms of custom use, thanks to the callbacks that allow to intercept the JSON line by line and to adjust the dumping of objects or resources according to their type.

It isn't required to use the framework to use this tool, however. You can see an example of the output format in this example on the project's github page, complete with a guide to some of the advantages and disadvantages of some of the current, more common methods of output. Several types are included in the example including simple string/integer values, objects, classes, stream resources and the results of variable casting.

In the past few years, JSON, or JavaScript Object Notation has seemed to overtake XML and other data encoding methods on the web. [...] I've also seen numerous examples of developers who create their own sort of JSON encoder rather than either using json_encode or using Zend_Json. What inevitably comes back to bite them is when the data they are encoding contains a special character like quotes, colons, curly brackets, etc.

He demonstrates how the Zend_Json component helps to alleviate some of the worries with built-in features that handle everything from basic encoding/decoding, printing out results in a "pretty" way and a handy way to include executable Javascript (once it's evaled on the other side) in your payload. He finishes the tutorial off with a mention of a very handy method that will please those already having to work with XML - the fromXML() method that automagically converts the data over to JSON for you.

There's a really horrible bug (though they won't call it that!) in Apache's mod_rewrite that means that urlencoded inputs in rewrites get unescaped in their transformation to output patterns. The bug actually remains unfixed, though a workaround first appeared in Apache 2.2.12. [...] Base-62 is interesting as it can be made safe for use in URLs, DNS, email addresses and pathnames, unlike any available encoding of base-64, as it only includes [0-9A-Za-z].

He originally wrote his own parser, but notes that now the BCMath and gmp extensions make it much simpler, just a call to gmp_strval with gmp_init. This method works, but it's still not quite all he wanted so he created his own encoder to do the job.

A few weeks later (my inbox is a black hole and it takes a while to process these things) I fell over a throwaway comment to an undocumented constant JSON_NUMERIC_CHECK, and I added the constant name to my todo list. In the time it took for me to actually get around to googling for this, some wonderful person updated the PHP manual page (this is why I love PHP) to include it as a documented option, and someone else had added a user contributed note about using it.

This option, JSON_NUMERIC_CHECK, tells the json_encode function to property consider numbers in its encoding process. It applies globally, so if there's an instance where you don't want something assigned as a number, you might need to go with another, more flexible JSON encoding option. You can find information about this and other possible options json_encode can take on its manual page.

For many PHP objects the JSON-representation of the data is a bit more complex.for instance what about private properties or maybe you want to calculate some inner values? - In PHP 5.3 you were on your own. but thanks to Sara there's hope in sight: the new interface JsonSerializable. Classes implementing this interface have to provide a method jsonSerialize() which will be called by json_encode() and has to return a JSON-compatible representation of the data by doing whatever you want.

He gives two examples of this new feature in action - a simple one that just spits out some basic JSON as a result of the output of a class and the other that's a bit more technical, involving multiple class isntances, a stdClass and a normal array.

Basically, data is coming into our PHP application through a Javascript's XMLHttpRequest (ajax). [...] Normally everything in the $_POST and $_GET arrays is already decoded, so when you're dealing with these arrays you don't really have to think about this. This time however, I was dealing with some non-latin unicode characters and for some reason they were never decoded and ended up in the database as raw url-encoded strings.

The issue was caused by the fact that the non-latin characters were handled differently on the byte level and that, because of the choice PHP makes on which of the unicode characters to use for spaces, he found that there were two options for handling strings - escape() and encodeURI().

While I was looking at some AJAX calls, I started to have a problem, for some reason, when I tried to query a JSON service I did using JQuery, the result was null for some fields. Going a little deeper, I notice that the records from the DB were OK, and the JavaScript was OK to, so what was the problem? The JSON Encode!

His issue stemmed from the character encoding of the string being passed into json_encode (in this case, UTF-8) was coming from a PHP script saved in a page encoded as ISO-8859-1. You can download the files he's come up with to illustrate the point.

We ran into a really hard to find bug in the cookie handling of Zend_Http_Client, which has been filed as a bug back in August 2007 against version 1.0.1 (today we are at 1.5.2). More over this is a bug that other similar packages have gotten over in 2004.

He had to use wireshark to finally track down the culprit - a call to urlencode on the contents of the cookie before sending it. He also includes some code to overcome a problem he had with UTF-16 in one of his feeds (a custom function that takes in and returns a string translated correctly).

However, the phpShield.com home page did not offer the slightest clue who actually is behind that product. [...] It's common practice to whitelabel your solutions and sell them under different brands with different feature sets to different target audiences. However, we always clearly state who is behind the whitelabelled solution.

A little more digging shows an interesting relationship between the company that sells SourceGuardian and the company behind this PHPShield (Inovica). He sees the deception counting against the company and has just "struck one off the list" from his search for encoding methods.

For the last several years, we have been successfully using the IonCube PHP encoder. It works well, providing us with as secure a solution as we could wish for, for our code. [...] Due to the amount of head pounding involved in finding this issue [where IonCube was removing a valid logic branch], I started to consider using Zend Guard instead, figuring that Zend has far more resources and more experience in this arena, we might see less issues.

He details their upgrade process including comments on the included GUI and how it "just works" (once it's set up)