Project homepage Mailing List  Warmcat.com  API Docs  Github Mirror 
{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1759695261, "reponame":"libwebsockets", "desc":"libwebsockets lightweight C networking library", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://libwebsockets.org/repo/libwebsockets", "f":3, "items": [ {"schema":"libjg2-1", "cid":"d508bf84097259ca97d756c8e6a4d8f7", "oid":{ "oid": "81830a397952e62d86eec5f532230627785e3ad2", "alias": []},"blobname": "READMEs/README.json-lejp.md", "blob": "# LEJP JSON Stream Parser\n\n|||\n|---|---|---|\n|cmake| `LWS_WITH_LEJP`|\n|Header| ./include/libwebsockets/lws-lejp.h|\n|api-test| ./minimal-examples/api-tests/api-test-lejp/|\n|test app| ./test-apps/test-lejp.c -\u003e libwebsockets-test-lejp|\n\nLEJP is a lightweight JSON stream parser.\n\nThe features are:\n\n - completely immune to input fragmentation, give it any size blocks of JSON as\n they become available, 1 byte, or 100K at a time give identical parsing\n results\n - input chunks discarded as they are parsed, whole JSON never needed in memory\n - nonrecursive, fixed stack usage of a few dozen bytes\n - no heap allocations at all, just requires ~500 byte context usually on\n caller stack\n - creates callbacks to a user-provided handler as members are parsed out\n - no payload size limit, supports huge / endless strings bigger than\n system memory\n - collates utf-8 text payloads into a 250-byte chunk buffer in the json parser\n context object for ease of access\n\n## Type handling\n\nLEJP leaves all numbers in text form, they are signalled in different callbacks\naccording to int or float, but delivered as text strings in the first\n`ctx-\u003enpos` chars of `ctx-\u003ebuf`.\n\nFor numeric types, you would typically use `atoi()` or similar to recover the\nnumber as a host type.\n\n## Callback reasons\n\nThe user callback does not have to handle any callbacks, it only needs to\nprocess the data for the ones it is interested in.\n\n|Callback reason|JSON structure|Associated data|\n|---|---|---|\n|`LEJPCB_CONSTRUCTED`|Created the parse context||\n|`LEJPCB_DESTRUCTED`|Destroyed the parse context||\n|`LEJPCB_COMPLETE`|The parsing completed OK||\n|`LEJPCB_FAILED`|The parsing failed||\n|`LEJPCB_VAL_TRUE`|boolean true||\n|`LEJPCB_VAL_FALSE`|boolean false||\n|`LEJPCB_VAL_NULL`|explicit NULL||\n|`LEJPCB_PAIR_NAME`|The name part of a JSON `key: value` map pair|`ctx-\u003ebuf`|\n|`LEJPCB_VAL_STR_START`|A UTF-8 string is starting||\n|`LEJPCB_VAL_STR_CHUNK`|The next string chunk|`ctx-\u003enpos` bytes in `ctx-\u003ebuf`|\n|`LEJPCB_VAL_STR_END`|The last string chunk|`ctx-\u003enpos` bytes in `ctx-\u003ebuf`|\n|`LEJPCB_ARRAY_START`|An array is starting||\n|`LEJPCB_ARRAY_END`|An array has ended||\n|`LEJPCB_OBJECT_START`|A JSON object is starting||\n|`LEJPCB_OBJECT_END`|A JSON object has ended||\n\n## Handling JSON UTF-8 strings\n\nWhen a string is parsed, an advisory callback of `LECPCB_VAL_STR_START` occurs\nfirst. No payload is delivered with the START callback.\n\nPayload is collated into `ctx-\u003ebuf[]`, the valid length is in `ctx-\u003enpos`.\n\nFor short strings or blobs where the length is known, the whole payload is\ndelivered in a single `LECPCB_VAL_STR_END` callback.\n\nFor payloads larger than the size of `ctx-\u003ebuf[]`, `LECPCB_VAL_STR_CHUNK`\ncallbacks occur delivering each sequential bufferload.\n\nThe last chunk (which may be zero length) is delievered by `LECPCB_VAL_STR_END`.\n\n## Parsing paths\n\nLEJP maintains a \u0022parsing path\u0022 in `ctx-\u003epath` that represents the context of\nthe callback events. As a convenience, at LEJP context creation time, you can\npass in an array of path strings you want to match on, and have any match\ncheckable in the callback using `ctx-\u003epath_match`, it's 0 if no active match,\nor the match index from your path array starting from 1 for the first entry.\n\n|CBOR element|Representation in path|\n|---|---|\n|JSON Array|`[]`|\n|JSON Map|`.`|\n|JSON Map entry key string|`keystring`|\n\n\n\n## Comparison with LECP (CBOR parser)\n\nLECP is based on the same principles as LEJP and shares most of the callbacks.\nThe major differences:\n\n - LEJP value callbacks all appear in `ctx-\u003ebuf[]`, ie, floating-point is\n provided to the callback in ascii form like `\u00221.0\u0022`. CBOR provides a more\n strict typing system, and the different type values are provided either in\n `ctx-\u003ebuf[]` for blobs or utf-8 text strtings, or the `item.u` union for\n converted types, with additional callback reasons specific to each type.\n\n - CBOR \u0022maps\u0022 use `_OBJECT_START` and `_END` parsing callbacks around the\n key / value pairs. LEJP has a special callback type `PAIR_NAME` for the\n key string / integer, but in LECP these are provided as generic callbacks\n dependent on type, ie, generic string callbacks or integer ones, and the\n value part is represented according to whatever comes.\n\n\n","s":{"c":1759695261,"u": 531}} ],"g": 2521,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 1, "si": 0, "db":0, "di":0, "sat":0, "lfc": "0000"}