Replies: 2 comments
-
|
However, I still really like this kind of thing. When the content length is similar and clean, this format is superior to both JSON and CSV. In the worst-case scenario, this format is still the "system performance optimal" choice. |
Beta Was this translation helpful? Give feedback.
-
|
You are pointing at a real edge case for TOON: arrays where one column is very long rich text (article body with code, URLs, markdown) and the other columns are tiny counters. From a correctness point of view the format is still unambiguous. The encoder will always quote any content that contains the active delimiter, and the header gives a fixed field order, so a trailing ",2" at the end of a row is always the like count and commas inside the body either appear inside quotes or (if you use tabs) are just regular characters. But you are right that in this shape of data the benefits are smaller and the rows are less pleasant to read. Two practical options:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Toon seems unsuitable for formats with uneven lengths and rich content.
Let me give an example: article titles, article content, like counts, comment counts, and bookmark counts. The length of article content is much longer than other fields and may contain image URLs, various special symbols, and code, such as code blocks. In this case, short-byte information in Toon mode is easily affected by long paragraphs, making it difficult to determine whether a simple ",2" refers to the main text content or the article's like count.
Beta Was this translation helpful? Give feedback.
All reactions