2010-02-24 9 views
22

Dati i seguenti due culture:.NET: ci sono differenze tra InvariantCulture e en-US?

CultureInfo c1 = InvariantCulture; 
CultureInfo c2 = new CultureInfo("en-US"); 

ed io eravamo ad esaminare ogni pezzo di informazioni specifiche per entrambe le culture, per es .:

c1.DateTimeInfo.ShortDatePattern; 
c2.DateTimeInfo.ShortDatePattern; 

c1.DateTimeInfo.LongDatePattern; 
c2.DateTimeInfo.LongDatePattern; 

c1.NumberFormat.CurrencyDecimalDigits; 
c2.NumberFormat.CurrencyDecimalDigits; 

c1.TextInfo.IsRightToLeft; 
c2.TextInfo.IsRightToLeft; 

avrei trovato le differenze?

In altre parole, l'InvariantCulture, per tutti gli scopi, è identica alla cultura "en-US"?

+1

Stai chiedendo questo solo come una curiosità? Ogni cultura ha casi d'uso specifici, che sono chiaramente definiti. Che siano o meno gli stessi è irrilevante per il processo di scrittura del software. –

+0

stavo chiedendo perché volevo sapere se posso usare InvariantCulture quando intendo davvero "non so cosa sia la cultura." Cosa sono io, Google ?! " Se sto cercando di analizzare una data, un valore monetario o un numero, non so in quale cultura si trovi. E anche qui in en-US, ci sono diversi modi di scrivere una data. Come faccio a sapere quale sottocultura di en-US intendesse la persona? Quindi, chiedendo delle differenze tra loro, stavo vedendo quanto spesso riesco a cavarmela usando InvariantCulture, piuttosto che forzare CurrentThreadCulture, CurrentUICulture o CurrentCulture. –

+3

Consiglierei di non provare a farla franca con niente. La cultura attuale dovrebbe essere usata per tutto ciò che non ha bisogno di essere invariante su macchine o cambiamenti culturali. Se stai tentando di analizzare dati sui quali non hai alcun controllo e che non corrispondono alla cultura corrente, non sono conformi a un particolare formato e non taggano la cultura che è stata utilizzata per crearlo, quindi, forse, la cultura dovrebbe essere selezionabile dall'utente o qualcosa del genere. Non penso che Invariant ti possa aiutare. –

risposta

28

Sì.

Ad esempio: InvariantCulture utilizza il simbolo internazionale per la valuta: "¤" rispetto al simbolo del dollaro: "$" durante la formattazione della valuta.

Per la maggior parte, tuttavia, sono molto simili.

Edit: Elenco delle differenze tra en-US e Invariant:

      en-US      Invariant 
=====================  ==================   ================== 
Number     123456.78     +123456.78 
Currency Symbol   $       ¤ 
Currency     $123456.78     ¤123456.78 
Short Date    1/11/2012     01/11/2012 
Time      10:36:52 PM     22:36:52 
Metric     No       Yes 
Long Date     Wednesday, January 11, 2012 Wednesday, 11 January, 2012 
Year Month    January, 2012    2012 January 
+4

Per citare MSDN: * "La proprietà InvariantCulture non rappresenta né una cultura neutra né una cultura specifica. Rappresenta un terzo tipo di cultura che è insensibile alla cultura. È associato con la lingua inglese ma non con un paese o una regione. "* ... Quindi ha senso comportarsi per la maggior parte come inglese (sebbene per il formato di data degli Stati Uniti strano avrei voluto vedere qualcosa di sano) ma la valuta sarebbe solo un'assurdità :) – Joey

+3

E un formato di data logico: yyyy-MM-dd pure. –

+1

Drat. Quindi provare ad analizzare una stringa di denaro con InvariantCulture non funzionerà da nessuna parte nel mondo. –

1

Breve risposta di sì. InvariantCulture è ciò che dice, non una cultura specifica. E 'inglese, ma non è una regione specifica

si può leggere di più qui: MSDN

4

Ci sono alcune differenze reali (controllare entrambi i valori in una finestra Watch), ma la differenza più rilevante è l'intento. InvariantCulture mostra il tuo intento di analizzare alcuni dati in un modo indipendente dalla cultura, se in inglese, mentre en-US dichiara il tuo intento reale di analizzare i dati in un modo specifico USA.

0

So che hanno un diverso CultureName e LCID (vedi this list).

Inoltre, i simboli di valuta sono diversi - ¤ per InvariantCulture e $ per en-US.

Da InvariantCulture:

It is used in almost any method in the Globalization namespace that requires a culture.

Suggerendo che per la maggior parte, sono intercambiabili. Tuttavia, i nomi hanno un intento statale, quindi dovresti pensarci quando usi CultureInfo.

2

Beh, se si guarda a ciò che il frammento di codice potrebbe produrre:

CultureInfo c1 = CultureInfo.InvariantCulture; 
CultureInfo c2 = new CultureInfo("en-US"); 

Console.WriteLine(c1.DateTimeFormat.ShortDatePattern.ToString()); 
Console.WriteLine(c2.DateTimeFormat.ShortDatePattern.ToString()); 

Console.WriteLine(c1.DateTimeFormat.LongDatePattern.ToString()); 
Console.WriteLine(c2.DateTimeFormat.LongDatePattern.ToString()); 

Console.WriteLine(c1.NumberFormat.CurrencyDecimalDigits.ToString()); 
Console.WriteLine(c2.NumberFormat.CurrencyDecimalDigits.ToString()); 

Console.WriteLine(c1.TextInfo.IsRightToLeft.ToString()); 
Console.WriteLine(c2.TextInfo.IsRightToLeft.ToString()); 

Vedrete alcune differenze:

MM/dd/yyyy 
M/d/yyyy 
dddd, dd MMMM yyyy 
dddd, MMMM dd, yyyy 
2 
2 
False 
False 

E proprio pensare, quando perde gli Stati Uniti è la spina dorsale e decide di iniziare ad usare le date in stile europeo o le mosse al sistema metrico (il sistema metrico è lo strumento del diavolo! La mia macchina ottiene quaranta canne fino alla botte e questo è il modo in cui mi piace!), InvariantCulture può rimanere semplicemente e senza intoppi così com'è. Quindi tutte le date che hai nascosto in un database in forma di testo usando InvariantCulture continueranno a funzionare ...

1

È molto importante considerare l'intento dei dati. Se stai serializzando assicurati di usare InvariantCulture.

See: http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.aspx

Dalla documentazione di Microsoft:

dinamica Cultura Dati

Fatta eccezione per la cultura invarianti, dati cultura è dinamica. Questo è true anche per le culture predefinite. ...

Attenzione

Durante il salvataggio dei dati, l'applicazione deve usare la cultura invarianti, utilizzare un formato binario, o utilizzare un formato specifico indipendente dalla cultura. I dati salvati in base ai valori correnti associati a una cultura particolare , diversa dalla cultura invariabile, potrebbero diventare illeggibili o potrebbero cambiare significato se tale cultura cambia.

L'ho appena rilevato di recente in cui l'utente ha impostato le impostazioni internazionali e della lingua in inglese (Stati Uniti), ma ha scelto il formato data personale in gg-MMM-aa. Ha ricevuto un progetto da un cliente con una data nel formato predefinito en-US "2010/04/29 13:45:30" e il codice:

customValue = DateTime.Parse (customValue.ToString (), CultureInfo.CreateSpecificCulture ("en-US"));

ha generato un'eccezione perché le sue preferenze locali hanno la precedenza ciò che il tipico formato di en-US.

Problemi correlati