Potrebbe esserci qualche impatto in quanto differiscono in ordine di ordinamento, relazioni maiuscole-minuscole, ordini di confronto, separatori di migliaia, simbolo di valuta predefinito e altro.
C.utf8 =locale predefinito conforme agli standard POSIX. Sono validi solo caratteri ASCII stretti, estesi per consentire l'uso di base di UTF-8
en_US.utf8 =Locale inglese americano UTF-8.
Anche se non sono sicuro dell'effetto specifico che potresti riscontrare, credo che tu possa impostare le impostazioni locali e la codifica all'interno della tua applicazione, se necessario.
Ecco alcuni motivi per cui ho aggiunto LC_TIME=C.UTF-8 in /etc/default/locale , nel caso in cui aiuti qualcuno:
Fornisce un orologio di 24 ore invece di AM/PM in Firefox per HTML5 input type=time (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time) e utilizza un datepicker nel formato GG/MM/AAAA anziché MM/GG/AAAA per l'input HTML5 type=date (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date).
Consente di utilizzare il formato di data internazionale AAAA-MM-GG (ISO 8601) con un orologio di 24 ore quando si risponde alle e-mail in Thunberbird.
In precedenza, era possibile con LC_TIME=en_DK.UTF-8 (http://kb.mozillazine.org/Date_display_format) ma al momento c'è un bug che ha smesso di funzionare (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c155).
Modifica:ora anche il LC_TIME=C.UTF-8 la soluzione alternativa non funziona per Thunberbird (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c197) ma almeno en_IE.UTF-8 fornisce il formato data europeo GG/MM/AAAA invece di MM/GG/AAAA.
In generale C è per computer, en_US è per le persone negli Stati Uniti che parlano inglese (e altre persone che vogliono lo stesso comportamento).
Il per computer significa che le stringhe sono a volte più standardizzate (ma ancora in inglese), quindi un output di un programma potrebbe essere letto da un altro programma. Con en_US , le stringhe potrebbero essere migliorate, l'ordine alfabetico potrebbe essere migliorato (forse con nuove regole delle regole di stile di Chicago, ecc.). Quindi più user-friendly, ma forse meno stabile. Nota:le impostazioni locali non servono solo per la traduzione delle stringhe, ma anche per le regole di confronto (ordine alfabetico, numeri (ad es. separatore delle migliaia), valuta (penso che sia sicuro prevedere che rimarranno $ e 2 cifre decimali), mesi, giorno della settimana , ecc.
Nel tuo caso, è solo la versione UTF-8 di entrambe le lingue.
In generale non dovrebbe importare. Di solito preferisco en_US.UTF-8, ma di solito non importa, e nel tuo caso (app server), dovrebbe cambiare solo il registro e i messaggi di errore (se usi locale.setlocale() . Dovresti gestire le impostazioni locali del client all'interno della tua app. I programmi che leggono da altri programmi dovrebbero impostare C prima di aprire la pipa, quindi non dovrebbe avere molta importanza.
Come vedi, probabilmente non importa. Puoi anche usare POSIX locale, definito anche in Debian. Ottieni l'elenco delle impostazioni locali installate con locale -a .
Nota:la micro-ottimizzazione prescriverà C /C.UTF-8 locale:nessuna traduzione dei file (gettext ) e semplici regole sulla raccolta e la formattazione dei numeri, ma questo dovrebbe essere visibile solo sul lato server.