Může to mít určitý dopad, protože se liší v pořadí řazení, vztazích s velkými malými písmeny, pořadí řazení, oddělovače tisíců, výchozí symbol měny a další.
C.utf8 =výchozí národní prostředí vyhovující standardům POSIX. Platné jsou pouze striktní znaky ASCII, rozšířené tak, aby umožňovaly základní použití UTF-8
en_US.utf8 =národní prostředí americké angličtiny UTF-8.
Nejsem si sice jistý konkrétním efektem, se kterým se můžete setkat, ale věřím, že v případě potřeby můžete nastavit národní prostředí a kódování uvnitř aplikace.
Zde je několik důvodů, proč jsem přidal LC_TIME=C.UTF-8 v /etc/default/locale , v případě, že to někomu pomůže:
Poskytuje 24hodinový čas namísto AM/PM ve Firefoxu pro HTML5 input type=time (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time) a používá datepicker ve formátu DD/MM/RRRR místo MM/DD/RRRR pro HTML5 input type=date (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date).
Umožňuje použití mezinárodního formátu data YYYY-MM-DD (ISO 8601) s 24hodinovým časem při odpovídání na e-maily v Thunberbirdu.
Dříve to bylo možné s LC_TIME=en_DK.UTF-8 (http://kb.mozillazine.org/Date_display_format), ale momentálně je tam chyba a přestala fungovat (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c155).
Edit:Nyní i LC_TIME=C.UTF-8 řešení nefunguje pro Thunberbird (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c197), ale alespoň en_IE.UTF-8 poskytuje evropský formát data DD/MM/RRRR namísto MM/DD/RRRR.
Obecně C je pro počítač, en_US je pro lidi v USA, kteří mluví anglicky (a další lidi, kteří chtějí stejné chování).
Pro počítač znamená, že řetězce jsou někdy více standardizované (ale stále v angličtině), takže výstup programu lze číst z jiného programu. S en_US , struny by mohly být vylepšeny, abecední řazení by mohlo být vylepšeno (možná novými pravidly chicagských pravidel stylu atd.). Tedy uživatelsky přívětivější, ale možná méně stabilní. Poznámka:národní prostředí nejsou jen pro překlad řetězců, ale také pro porovnávání (abecední pořadí, čísla (např. oddělovač tisíců), měnu (myslím, že je bezpečné předvídat, že zůstanou $ a 2 desetinné číslice), měsíce, dny v týdnech , atd.
Ve vašem případě je to pouze verze UTF-8 obou lokalit.
Obecně by to nemělo vadit. Obvykle dávám přednost en_US.UTF-8, ale obvykle na tom nezáleží a ve vašem případě (serverová aplikace) by to mělo změnit pouze protokol a chybové zprávy (pokud používáte locale.setlocale() . Lokality klienta byste měli zpracovávat ve své aplikaci. Programy, které čtou z jiných programů, by měly nastavit C před otevřením potrubí, takže by to vlastně nemělo vadit.
Jak vidíš, asi je to jedno. Můžete také použít POSIX locale, definujte také v Debianu. Seznam nainstalovaných lokalit získáte s locale -a .
Poznámka:Mikrooptimalizace předepíše C /C.UTF-8 národní prostředí:žádný překlad souborů (gettext ) a jednoduchá pravidla pro řazení a formátování čísel, ale to by mělo být viditelné pouze na straně serveru.