UTF-8 sta diventando sempre più comune praticamente ovunque (W3Techs nel giugno 2015 mette UTF-8 all'84,3% sul web ), non ha penalità di archiviazione su US-ASCII per l'intervallo US-ASCII (da U + 0000 a U + 007F) (a seconda dell'implementazione il BOM può comportare una penalità di tre byte, ma una distinta base è solo necessario se la codifica e / o l'ordine dei byte non sono altrimenti noti, quale sarebbe in questo caso), e può rappresentare l'intera gamma di Unicode in modo tale da rendere la tua applicazione a prova di futuro senza alcun costo aggiuntivo se tu non usi quella capacità. In sintesi, non vedo alcun motivo non per utilizzare la codifica UTF-8 in questi giorni, in particolare se le tue scelte sono tra UTF-8 e US-ASCII. E anche in un mondo esclusivamente americano, sarei molto cauto nel dire che non ci sarà "nessuna necessità" di codificare alcuna lettera al di fuori dell'alfabeto inglese.
Sono abbastanza sicuro di aver visto un RFC di qualche anno fa che affermava che UTF-8 è il nuovo set di caratteri standard di Internet (in sostituzione di US-ASCII), ma poi non sono riuscito a trovarlo di nuovo. Tuttavia, BCP 18 (RFC 2277) sezione 3.1, Quale set di caratteri da utilizzare , si avvicina a affermando che, in parte:
All protocols MUST identify, for all character data, which charset is
in use.
Protocols MUST be able to use the UTF-8 charset, which consists of
the ISO 10646 coded character set combined with the UTF-8 character
encoding scheme, as defined in [10646] Annex R (published in
Amendment 2), for all text.
Protocols MAY specify, in addition, how to use other charsets or
other character encoding schemes for ISO 10646, such as UTF-16, but
lack of an ability to use UTF-8 is a violation of this policy; such a
violation would need a variance procedure ([BCP9] section 9) with
clear and solid justification in the protocol specification document
before being entered into or advanced upon the standards track.