Formdata Spanish accents or other special characters don't show up as one would expect

[luthfib]

Describe the bug

When creating fomData with name fields with accents such as the word "Género", when parsing in the server it shows up as garbled text such as "Género". I believe the the behavior would be that it would show up as "Género", but please correct me if I am wrong.

Reproduction

Link to the reproduction below in the following repo: https://github.com/luthfib/sveltekit-bug-repro. I created a minimal sveltekit repo that has two input fields and a submit button using use:enhance. Once the data is submitted I have. validate action that receives it and upon inspecting the data in the server it can be seen that the characters are not encoded as one would expect.

Logs

No response

System Info

System:
    OS: macOS 13.0.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 98.81 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.4.0 - ~/.nvm/versions/node/v18.4.0/bin/node
    npm: 8.13.2 - ~/.nvm/versions/node/v18.4.0/bin/npm
  Browsers:
    Brave Browser: 98.1.35.101
    Chrome: 107.0.5304.110
    Firefox: 107.0
    Safari: 16.1
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.89 
    @sveltejs/kit: next => 1.0.0-next.563 
    svelte: ^3.44.0 => 3.53.1 
    vite: ^3.1.0 => 3.2.4

Severity

annoyance

Additional Information

No response

[Conduitry]

This seems to be specific to progressively enhanced forms. Presumably the response to the request to the underlying action should have a content-type that indicates it's UTF-8 encoded, but I'm not sure where that needs to happen.

[gtm-nayan]

More generally, it seems to be stemming from how FormData works.

The FormData interface provides a way to easily construct a set of key/value pairs representing form fields and their values, which can then be easily sent using the fetch() or XMLHttpRequest.send() method. It uses the same format a form would use if the encoding type were set to "multipart/form-data"
-- MDN

It also adds a "boundary" to the header: multipart/form-data; boundary=---------------------------204642726716197698553061806070 which I don't see a way of obtaining but the server throws a TypeError if it's not present.

By default (w/o progressive enhancement) form submissions are application/x-www-form-urlencoded, but adding an enctype=multipart/form-data breaks it as well.

[repsac-by]

It seems to be a busboy bug that undici depends on.
Although deno behaves the same way.
But in the browser everything is correct.

const formData = new FormData();
formData.append('Género', '1');

const request = new Request('http://localhost', {
    method: 'POST',
    body: formData
});

console.log(...await request.formData());

node, deno

// [ 'Género', '1' ]

chromium, firefox

// ['Género', '1']

[repsac-by]

https://github.com/mscdex/busboy#exports

defParamCharset - string - For multipart forms, the default character set to use for values of part header parameters (e.g. filename) that are not extended parameters (that contain an explicit charset). Default: 'latin1'.

If i specify utf8, this solve.
But from SvelteKit there is no way to directly influence the configuration busboy.

[repsac-by]

nodejs/undici#1786

[luthfib]

It seems they released the fix under version v5.14.0

[Conduitry]

This has been updated in #7995, although not yet released I don't think.

@Rich-Harris That probably should have had a changeset added, because that upgrade is a user-visible change. I'm not sure how we want to handle this now.

[Conduitry]

@sveltejs/kit@1.0.0-next.575 include the update to undici@5.14.0, so this should be fixed now.