Deserialisation (in this context) is the act of decoding data from some "string representation" to a representation suitable for use, typically a native format.

Typically, although this depends on the specific encoding, a parser is required as one of the first stages of a deserialiser; normally a parser refers to something which applies the rules of something as least as complex as a CFG, as opposed to a lexer/scanner which typically just applies regular expressions; a combination of the two allows the serialised format to be interpreted.

You can show quite easily that JSON (and indeed any CFL) cannot be "parsed" using a lexer alone.

Serde includes a bunch of parsers by default but if you invented a new text file format, you’d have to write a new parser for it before you could do anything with it, and serde doesn’t help with that.

Good question, thanks.

I had the vague notion that parsing was for human readable content and deserialization was for computer-to-computer content.

Now I tentatively make the distinction that compiling transforms streams into code (stream -> lex -> parse -> magic -> code) whereas deserialization is for data. Making parsing just one of the transformation steps for both compilation and deserialization.

Serde only helps with moving the values from the parser into a struct. It doesn't help with figuring out the data format.

The really essential difference is that when you deserialize, you trust the input, and so don't need to check syntax or validity. I.e., you assume it is output of your own serializer, and you can therefore be faster than if you didn't trust it.

I have no idea if serde follows this design, or if it has just hijacked the terms.