Keep encoding and upload safety separate

For binary-capable contexts such as HTTP, senders SHOULD NOT generate Content-Transfer-Encoding part headers.

• A binary-capable transport can carry the fixture bytes 00 7F 80 FF directly in a part body. Do not add MIME Base64 merely because this is multipart. Restricted transports have different considerations; section 4.7 deprecates transfer encoding for binary-capable contexts.
• Filename characters MAY be encoded using the UTF-8 percent-encoding option (section 2). For example, café.txt can be represented as caf%C3%A9.txt. This describes a filename parameter, not percent-encoding of the entire binary file body, and does not promise every receiver will decode it the same way.
• The filename* parameter specified by RFC 5987 MUST NOT be used in multipart/form-data. Do not copy the rules for an HTTP response’s Content-Disposition field into this different context.
• Other part header fields beyond the permitted Content-Disposition, Content-Type and limited Content-Transfer-Encoding cases MUST NOT be included and MUST be ignored. Do not invent a part Content-Length requirement.
• RFC 7578 supplies no integrity checking, confidentiality or general security protection. File bodies may be executable; filenames can cause overwrites if used blindly. Applications need their own authorization, storage, content and transport protections. The final hold-for-checks gate is an illustrative application policy.

No network request, file read, filesystem write, live upload or account operation is performed by these scenes. The bytes, filenames and values are fictional QA fixtures. The body encoder is bounded format teaching code, not a production upload service or security validator.