Decode text using its character encoding

An explicit part charset and an application’s default charset have different scopes.

• For text/plain form data, a charset parameter MAY identify that part’s character encoding. Content-Type itself remains optional and defaults to text/plain when absent.
• In this fixture, café encoded as UTF-8 has hexadecimal bytes 63 61 66 C3 A9: four characters and five bytes. With Content-Type: text/plain; charset=UTF-8, the receiver can interpret those particular bytes accordingly.
• Some applications use a hidden _charset_ entry to establish a default for text/plain parts that omit their own charset. This is a convention described in section 4.6, not a required field in every multipart body.
• An explicit per-part charset supplies that part’s encoding instead of the default. The ISO-8859-1 encoding of café has hexadecimal bytes 63 61 66 E9, four bytes; decoding it as UTF-8 is not equivalent.
• Form creators SHOULD avoid non-ASCII field names for interoperability and SHOULD use UTF-8 uniformly if such names are unavoidable (section 5.1.1). Other application context may be needed when no charset parameter or _charset_ value is supplied. Historical HTML selection rules are described in section 5.1.2; this guide does not claim to implement the current HTML form algorithm.

The teaching helper supports only UTF-8 and ISO-8859-1 and rejects unsupported encodings as outside its scope. It does not classify every other registered charset as invalid multipart data. Verified erratum 4676 is respected: the _charset_ part uses an intermediate delimiter, not a premature closing delimiter.