Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Specify how filenames from the OS map to File's `name` property

Aperta
#161 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
html
Ambito
api, web-dev

Direzione di ricerca

Leggi il testo di File API che descrive come un nome di file di un OS diventa il nome di un File, quindi confronta gli algoritmi collegati di Encoding e HTML. L'issue è completata quando la specifica definisce normativamente la gestione dei nomi di file non validi e il comportamento risultante di File, senza lasciare irrisolte differenze tra i browser.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

I've been testing how files coming from the OS get exposed as File objects, and in particular how filenames that aren't in the OS's default encoding get mapped to the name property.

In Windows systems, filenames are sequences of UTF-16 code units (not UTF-16 encoded text, as is sometimes claimed, because the system APIs don't check for lone surrogates), and as expected, they directly map to a DOMString. An initial BOM doesn't get removed. There doesn't seem to be any browser differences here.

In Unix systems (tested on Fedora Linux; my understanding is all other modern Unix variants/distros work the same), filenames are byte sequences, which are usually taken to be UTF-8. Here's how the various browsers behave on them:

  • Firefox does the equivalent of UTF-8 decode without BOM, decoding bytes which aren't valid UTF-8 as a replacement character.
  • WebKit does the equivalent of UTF-8 decode without BOM or fail, and handles failures by returning a File object with the empty string as filename, empty contents, and MIME type application/octet-stream instead. The language around name in the spec might allow for an empty string to substitute a filename that cannot be decoded, but it doesn't allow the content to be dropped. Note that the resulting File object is identical to the File object that HTML's "construct the entry list" creates when a file input has no selected files.
  • Chrome also does the equivalent of UTF-8 decode without BOM or fail, except that for file inputs, any file whose filename isn't UTF-8 gets dropped from the selection. For drag and drop, Chrome behaves the same as WebKit.

Since it doesn't seem good to drop files or replace them by an empty file, even when their filenames don't match the OS's conventions, it seems like it would be best to agree on Firefox's behavior.

Lingua principale
HTML
Stelle
118
Fork
52
Merge medio
9g 16h
PR unite (30g)
1

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di w3c/FileAPI

Tutte le issue di w3c/FileAPI

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.