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.

Unfortunately right now there are quite a few issues with taking a 3rd party Bundle which wasn't specifically build to be accessible via JSON. So in the end I build a MultiplexController that can JSON-ify any controller. The name derives from the fact that it also supports calling multiple routes at once and returning all the data from all these routes in one request. But being good OSS citizens here at Liip, we decided to use this opportunity to try and come up with a more sustainable solution. The goal would be to make it essentially possible to have a 3rd party controller return JSON without having to do anything on the controller level.

He talks about the "magic" that lets you define the output format you'd like and how it works on the backend with the templating system to use templates based on the requested file. He points out a few issues with the method - a form request problem and that there's no good way to call json_encode from inside a twig template (as well as redirecting after submission).

One solution that I did, in order to preserve the character set was to encode the data before using the json_encode function to use just A-Z, a-z and 0-9 characters, instead of sending text with accents or symbols. One encoding that fits perfectly in this schema, is Base64 Content-Transfer-Encoding. (see base 64 explanation below) This leads me to the solution: Encode the ISO-8859-1 using base64 and decoded in the client using JavaScript.

He includes both a code example for his solution and downloadable code for you to try it out yourself.

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.

Today I looked for a replacement for my old jspanserializer.js script that I can't even remember where I found anymore. Turns out that I wont have to either, I can forget it. From now on I'll use jQuery JSON instead.

A code example is included to show the simplicity.

Recently I've had the need to extend the interface further, among other things with JSON support. I've used code published by Nicolas Crovatti to do this.

His example shows how the script works to plot out some points for a table of stats. He follows this with an in-depth look at the different methods making up that fluent call (apply2Field, fill_ret, sum and plot). These make the array that can then be passed off to PHP, using json_encode to make an easy-consumable JSON message out of the results.