JSONH is one of the most performant, yet safe, cross programming language, way to pack and unpack generic homogenous collections.
Based on native or shimmed JSON implementation, JSONH is nothing different than a procedure performed right before JSON.stringify(data) or right after JSON.parse(data)

It is demonstrated that overall performances of JSONH are up to 3 times faster in compression and 2 times in parsing thanks to smaller and simplified nature of the collection/string.

It is also demonstrated that resulting bandwidth size will be incrementally smaller than equivalent JSON operation reaching, in certain cases, down to 30% of original size and without gzip/deflate compression in place.

Usually a database result set, stored as list of objects where all of them contains the same amount of keys with identical name.
This is a basic homogeneous collection example: [{"a":"A","b":"B"},{"a":"C","b":"D"},{"a":"E","b":"F"}]
We all have exchange over the network one or more homogenous collections at least once.
JSONH is able to pack the example into [2,"a","b","A","B","C","D","E","F"] and unpack it into original collection at light speed.

Every implementation is suitable for the programming language code style and every method supports original JSON signature.
As example the JavaScript version is a global JSONH object with stringify, parse, pack, and unpack methods.

The python version is a module similar to json one with current methods: dump, dumps, load, loads, pack, and unpack.

clean up locally tests and use a standard one able to cover all aspects per each implementation

C# version, and hopefully with other developers help other languages too

simplified yet cross platform way to map hybrid objects, specifying via white list one or more nested properties to pack on stringify, and unpack on parse (automated and addressed compression for complex objects)

As @garethheyes pointed out by in this post, native JSON.stringify(data) may produce invalid JavaScript.
Since JSONH aim is not to change native JSON behavior, neither is JSONH a replacement for JSON, all I can suggest is to perform this replacement when and if data could be corrupted:

This will ensure proper escape for those characters plus performances will be still better thanks to reduced string output size (compared with the euivalent operation performed by JSON.stringify(data)).