<P> With this type of file structure, tools that do not know certain chunk identifiers simply skip those that they do not understand . Depending on the actual meaning of the skipped data, this may or may not be useful (CSS explicitly defines such behavior). </P> <P> This concept has been used again and again by RIFF (Microsoft - IBM equivalent of IFF), PNG, JPEG storage, DER (Distinguished Encoding Rules) encoded streams and files (which were originally described in CCITT X. 409: 1984 and therefore predate IFF), and Structured Data Exchange Format (SDXF). </P> <P> Indeed, any data format must somehow identify the significance of its component parts, and embedded boundary - markers are an obvious way to do so: </P> <Ul> <Li> MIME headers do this with a colon - separated label at the start of each logical line . MIME headers cannot contain other MIME headers, though the data content of some headers has sub-parts that can be extracted by other conventions . </Li> <Li> CSV and similar files often do this using a header records with field names, and with commas to mark the field boundaries . Like MIME, CSV has no provision for structures with more than one level . </Li> <Li> XML and its kin can be loosely considered a kind of chunk - based format, since data elements are identified by markup that is akin to chunk identifiers . However, it has formal advantages such as schemas and validation, as well as the ability to represent more complex structures such as trees, DAGs, and charts . If XML is considered a "chunk" format, then SGML and its predecessor IBM GML are among the earliest examples of such formats . </Li> <Li> JSON is similar to XML without schemas, cross-references, or a definition for the meaning of repeated field - names, and is often convenient for programmers . </Li> <Li> Protocol buffers are in turn similar to JSON, notably replacing boundary - markers in the data with field numbers, which are mapped to / from names by some external mechanism . </Li> </Ul>

How do you find out a file's format