We have some unexpected behavior with POCO::JSON implementation. There are two main problems that touches Json encoding and decoding:

1. Encoding and decoding of buffer that contains zero byte(s) sequence. It is impossible to decode sequence that was previously encoded with POCO Json.
2. Encoding of the bytes/characters that need to be encoded to have compatibility with many well-known Json libraries. Zero byte, Upper ASCII and utf-8 multi-byte characters expected to be encoded as Unicode hexadecimal, for example: string like:
   “zero byte=[\0x0], upper ASCII=[fenêtre] and multi-byte characters=[こんにちは]”
   need to be represented as:
   “zero byte=[\u0000x0], upper ASCII=[fen\u00eatre] and multi-byte characters=[\u3053\u3093\u306b\u3061\u306f]”.
3. Last but not from web directory implementation seems has memory leaks in library:
   LEAK SUMMARY:
   ==15836== definitely lost: 1,916 bytes in 16 blocks
   ==15836== indirectly lost: 7,314 bytes in 104 blocks
   ==15836== possibly lost: 0 bytes in 0 blocks
   ==15836== still reachable: 0 bytes in 0 blocks
   ==15836== suppressed: 0 bytes in 0 blocks
   =15836== 8 bytes in 2 blocks are definitely lost in loss record 3 of 36
   ==15836== at 0x402B733: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
   ==15836== by 0x4070F74: Poco::JSON::ParseHandler::startObject() (in /usr/local/lib/libPocoJSON.so.21)
   ==15836== by 0x4576A97: ???

We have implemented some serialization messages classes based on POCO Json implementation, but have several inequalities of implementations of POCO and client-side libraries.