Repository navigation
Specify HTML numeric character reference fallback encoding for multipart upload filename characters not representable in form charset #3223
Description
Specify HTML numeric character reference fallback encoding for multipart upload filename characters not representable in form acceptCharset/form charset.
Rationale:
- Consistency: this will make filename fallback character replacement consistent with encoding of form element names and values in multipart uploads when a source character is not representable in the
acceptCharset/form charset. @annevk points out that this is exactly the "html" error handling of the Encoding Standard. https://encoding.spec.whatwg.org/#concept-encoding-process - Predictability: this is consistent with existing behavior in at least two browsers (Firefox and Edge). I have also started an intent to implement and ship thread for this behavior for Chrome. edit: this proposal was accepted, I'm now working to implement it in Chrome
- Reduced data loss: this change reduces the risk of user confusion and website malfunction when multiple uploaded files with distinct local filenames but identical representation after user agent-specific fallback character replacement are uploaded using
<input type=file multiple>; with this behavior standardized, web pages may even be able to portably recover useful user-visible representations of the original filenames, though some ambiguity remains with that approach as a local file could actually contain name parts matching numeric character references (moving to UTF-8 for the form submission of course resolves the ambiguity and should be the only recommended solution for newly-built web pages).
Accidentally filed here too: w3c/html#1077
Activity
annevk commentedon Nov 14, 2017
Currently we have:
If we use https://encoding.spec.whatwg.org/#encode this will happen automatically. The problem is that HTML passes strings to the RFC "algorithms" which are supposed to handle all the encoding requirements.
A proper fix would require replacing the RFC I think.
annevk commentedon Nov 14, 2017
Replacing the RFC is #3040 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909.
bsittler commentedon Nov 14, 2017
An example: if the filename were
ABC~‾¥≈¤･・•∙·☼★星🌟星★☼·∙•・･¤≈¥‾~XYZ≈.txtand the form charset were ISO-2022-JP the expected encoded name would beABC~⊖(J~\≈¤⊖$B!&!&⊖(B•∙·☼⊖$B!z@1⊖(B🌟⊖$B@1!z⊖(B☼·∙•⊖$B!&!&⊖(B¤≈⊖(J\~⊖(B~XYZ≈.txta.k.a.ABC~␛(J~\≈¤␛$B!&!&␛(B•∙·☼␛$B!z@1␛(B🌟␛$B@1!z␛(B☼·∙•␛$B!&!&␛(B¤≈␛(J\~␛(B~XYZ≈.txt(here⊖or␛pictorially represents the ESC C0 control x1B); beware the information-losing unification of halfwidth and fullwidth forms, in addition to the information loss due to inability to distinguish literal and replacement numeric character reference-like sequences; the actual solution to those problems is UTF-8, but so long as non-UTF-8 charsets are still used this will at least reduce information loss compared to e.g.?substitution.bsittler commentedon Dec 6, 2017
Given that this issue is still open, should the tests I'm adding in https://crrev.com/c/811625 be .tentative. ?
WPT: Add form-based file upload coverage
WPT: Add form-based file upload coverage
domenic commentedon Dec 6, 2017
Yeah. Were you interested in updating the spec too?
bsittler commentedon Dec 6, 2017
Sure!
How does a non-editor do that?Edit: n/m, I see CONTRIBUTING.md nowWPT: Add form-based file upload coverage
WPT: Add form-based file upload coverage
bsittler commentedon Dec 6, 2017
@annevk @domenic I have attempted to change HTML to match in #3276 - would you be suitable reviewers?
WPT: Add form-based file upload coverage
annevk commentedon Mar 1, 2021
@andreubotella ended up fixing this in #6282.