A change was introduced for RESTEASY-2046 to encode non-US-ASCII filenames per RFC 5987, but the fix was incorrect/incomplete.
Also latest RFC for multipart messages inside HTTP is defined in RFC-7578 and there is stated:

• NOTE: The encoding method described in RFC5987, which would add a "filename*" parameter to the Content-Disposition header field, MUST NOT be used.

Commons FileUpload library cannot consume file correctly if filename is like filename*=utf-8''Test%20file.pdf
Therefore, please add into method MultipartFormDataOutput.addFormData(String key, Object entity, MediaType mediaType, String filename) the parameter that will disable filename encoding

WF receives this by:

• Firefox client: Content-Disposition: form-data; name="key"; filename="La_R��gle_du_jeu"
• Jersey client: Content-Disposition: form-data; filename="La_R��gle_du_jeu"; modification-date="Thu, 07 Feb 2019 08:11:20 GMT"; size=4; name="key"
• RESTEasy 3.0.24 client (WF11): Content-Disposition: form-data; name="key"; filename="La_R��gle_du_jeu"
• RESTEasy 3.6.1 client (WF14): Content-Disposition: form-data; name="key"; filename*=utf-8''La_R%C3%A8gle_du_jeu

Default behaviour should be 'filename="non-encoded-characters"', we can consider to use some optional client parameters that allows to use "%" encoding. According to chapter 2 of rfc7578, we can consider to use something like 'filename="La_R%C3%A8gle_du_jeu"' if this approach is required by some client (java) property (because of backward compatibility). In this case, RESTEASY-2046 issue needs to be considered as well.

Cloned from RESTEASY-2148