Diferencia entre CultureInfo.CreateSpecificCulture() y el constructor de la clase?
La clase CultureInfo proporciona dos formas de creación:
- a través de un método de fábrica CreateSpecificCulture(string).
- a través de un constructor con un argumento de cadena
La documentación de MSDN difiere ligeramente para los dos, mencionando alguna "cultura de Windows" para el constructor. ¿Pero eso realmente importa?
¿Debería preferir uno de los dos sobre el otro?
Nota: Estoy usando. NET versión 3.5 si eso importa, y quiero para usarlo de esta manera:
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(culture);
Thread.CurrentThread.CurrentUICulture = new CultureInfo(culture);
3 answers
El método factory tiene una reserva cuando falla al crear la información de la cultura.
Así que si utilizas una cultura específica como 'en-XX', no se puede crear la instancia de culture info, se lanzará una excepción y un reintento con la cultura neutral 'en' tendrá éxito.
Debajo de la fuente del método de fábrica
public static CultureInfo CreateSpecificCulture(string name)
{
CultureInfo info;
try
{
info = new CultureInfo(name);
}
catch (ArgumentException)
{
info = null;
for (int i = 0; i < name.Length; i++)
{
if ('-' == name[i])
{
try
{
info = new CultureInfo(name.Substring(0, i));
break;
}
catch (ArgumentException)
{
throw;
}
}
}
if (info == null)
{
throw;
}
}
if (!info.IsNeutralCulture)
{
return info;
}
return new CultureInfo(info.m_cultureData.SSPECIFICCULTURE);
}
Así que prefiero el método de fábrica.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-06-25 15:54:59
Este hilo ya ha sido respondido, pero me encontré con un hallazgo único para CreateSpecificCulture API que podría no ser tan obvio a veces. Así que consideré este hilo como un lugar apto para mis hallazgos. Pasé unos días en esto, así que pensé en compartir mi experiencia si también puede ahorrar algunas horas o días para otros.
Durante el uso de la API cuando se pasa solo el nombre de la cultura como pt (para portugués) o de (para alemán) esta API devuelve una cultura específica correspondiente a la configuración regional que se denomina configuración regional predeterminada para esa cultura. Ahora bien, este lugar podría no ser tan obvio como suena donde me quedé atascado. Para alemán, de-DE parece obvio que es alemán hablado en Alemania. Para italiano, it-IT parece obvio que es italiano hablado en Italia.
Del mismo modo pt-PT parece obvio para el portugués hablado en Portugal. Desafortunadamente este es no el caso. Basado en no está seguro de qué razón exacta (puede ser población, país de origen, nacional idioma, etc.) existe una estandarización global basada en la cual se decide la configuración regional predeterminada para una cultura determinada cuando se intenta crear una cultura específica a partir de un id de cultura (pt en este caso). Microsoft ha documentado toda la lista en el siguiente enlace:
Http://msdn.microsoft.com/en-us/goglobal/bb896001.aspx
Si desea saber cuál es la configuración regional de país predeterminada para una cultura o idioma determinado, simplemente haga coincidir el código de la última columna (Abreviatura del nombre del idioma) en el enlace anterior.
Para el portugués, la abreviatura del nombre de la lengua de la cultura invariante "Portugués" coincide con "Portugués (Brasil)" que es PTB. Portugués (Portugal) tiene un código diferente PTG. Así que en este caso Portugués (Brasil) es la configuración regional predeterminada para el idioma portugués.
Si la lógica o los requisitos de su aplicación dependen de alguna manera de este comportamiento de esta API, debe ser cauteloso. Este comportamiento se vuelve más importante en aplicaciones basadas en web como todos los navegadores en el mercado también siguen estas pautas y envían la información adecuada en el encabezado de solicitud http cuando está mirando una versión localizada de un sitio web multilingüe.
Todavía estoy buscando la razón que es EL factor detrás de establecer un país específico como local predeterminado para cualquier cultura que no suene tan obvio en el caso del portugués. Cualquier información o comentario son bienvenidos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-02-12 05:50:49
Hay otra diferencia notable entre el método factory y el contructor: El constructor ofrece un booleano opcional adicional, que tiene su valor predeterminado en true.
Necesitará que este booleano se establezca en false, si realmente necesita un >"plain"de-DE) sin "Boolean set to false", siempre obtendrá una configuración de cultura, que podría tener configuraciones inesperadas, dependiendo de cómo el usuario haya cambiado esto cultivo a través del Panel de control.
¡El método factory no soporta este booleano !!!
Solo dos pensamientos finales sobre cuándo quieres que sea este booleano:
- true: Está generando salida para su interfaz de usuario - Esta salida debe estar de acuerdo con la configuración de Cultura específica, que el usuario ha elegido a través del Panel de control
- false: Desea analizar datos (por ejemplo, de XML) y conoce la configuración específica de la cultura XML (por ejemplo, el separador decimal como coma). En este caso usted necesita una
plain de-DE- Culture para estar seguro de que esa configuración especial del panel de control no interferiría.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-09-17 21:49:51