Represents structured data for Literal Data Packet.

Example:

iex> alias OpenPGP.LiteralDataPacket
...> data = <<0x62, 11, "example.txt", 1704328052::32, "Hello!">>
...> LiteralDataPacket.decode(data)
{
  %LiteralDataPacket{
    created_at: ~U[2024-01-04 00:27:32Z],
    data: "Hello!",
    file_name: "example.txt",
    format: {<<0x62>>, :binary}
  },
  <<>>
}

RFC4880

5.9. Literal Data Packet (Tag 11)

A Literal Data packet contains the body of a message; data that is not to be further interpreted.

The body of this packet consists of:

• A one-octet field that describes how the data is formatted.

If it is a 'b' (0x62), then the Literal packet contains binary data. If it is a 't' (0x74), then it contains text data, and thus may need line ends converted to local form, or other text-mode changes. The tag 'u' (0x75) means the same as 't', but also indicates that implementation believes that the literal data contains UTF-8 text.

Early versions of PGP also defined a value of 'l' as a 'local' mode for machine-local conversions. RFC 1991 [RFC1991] incorrectly stated this local mode flag as '1' (ASCII numeral one). Both of these local modes are deprecated.

• File name as a string (one-octet length, followed by a file name). This may be a zero-length string. Commonly, if the source of the encrypted data is a file, this will be the name of the encrypted file. An implementation MAY consider the file name in the Literal packet to be a more authoritative name than the actual file name.

If the special name "_CONSOLE" is used, the message is considered to be "for your eyes only". This advises that the message data is unusually sensitive, and the receiving program should process it more carefully, perhaps avoiding storing the received data to disk, for example.

• A four-octet number that indicates a date associated with the literal data. Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time.

• The remainder of the packet is literal data.

  Text data is stored with <CR><LF> text endings (i.e., network- normal line endings). These should be converted to native line endings by the receiving software.