c# .net globalization casing regioninfo

c# - ¿Por qué es ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ el nombre nativo de los Estados Unidos?



.net globalization (1)

Lo primero que se debe tener en cuenta es que el constructor de RegionInfo encuentra la región mediante la búsqueda de una cultura utilizada en esa región . Entonces está buscando un idioma en ese país, no solo el país.

Al leer ese código fuente, parece que la diferencia entre mayúsculas y minúsculas se debe a cómo se realizan las búsquedas si no se especifica una cultura con la región.

Por ejemplo, primero intenta un par de cosas, pero luego intentará buscar en una lista estática de regiones . Pero debido a que utiliza Dictionary.ContainsKey , es una búsqueda que distingue entre mayúsculas y minúsculas. Por lo tanto, si especifica "US" , lo encontrará, pero no "us" .

Más tarde, busca en la región que le diste a través de todas las culturas (de CultureInfo.GetCultures(CultureTypes.SpecificCultures) ), pero lo hace de una manera que no distingue entre mayúsculas y minúsculas.

No puedo confirmar ya que no puedo pasar por ese código, pero supongo que, debido a que está revisando la lista en orden, llegará a chr-Cher-US antes de que llegue a en-US .

¿Por qué no es consistente?

Uno de los comentarios dijo que LinqPad encuentra a Cherokee incluso cuando usa mayúsculas. No sé por qué esto es. Pude replicar eso, pero también encontré que en Visual Studio, es inglés cuando se usa "US" y Cherokee cuando se usa "us" , como usted describe. Pero encontré que si activo "Usar ensamblajes experimentales de Roslyn" en LinqPad, entonces vuelve el inglés para "US" y "us" . Así que tal vez tenga algo que ver con la versión exacta del tiempo de ejecución apuntada, no puedo asegurarlo.

Una cosa que afecta la consistencia es el almacenamiento en caché : lo primero que hará cuando no obtenga una coincidencia completa por cultura + región es verificar un caché de culturas ya encontradas . Es minúsculas todas las claves en ese caché, por lo que este caché no distingue entre mayúsculas y minúsculas.

Puedes probar esto. Sabemos que usar "US" frente a "us" producirá resultados diferentes, pero intente esto en el mismo programa:

var nativeNameus = new RegionInfo("us").NativeName; var nativeNameUS = new RegionInfo("US").NativeName;

Luego intercambiarlos y ejecutarlo de nuevo:

var nativeNameUS = new RegionInfo("US").NativeName; var nativeNameus = new RegionInfo("us").NativeName;

Ambos resultados siempre serán iguales porque la primera cultura se almacena en caché y se usa para la siguiente.

Es posible que exista un código fuera de su código que llame a los mismos métodos y termine almacenando en caché un valor cultural, cambiando así el resultado que obtiene cuando hace lo mismo.

Conclusión

Todo lo dicho, los documentos realmente dicen :

Recomendamos que utilice el nombre de la cultura, por ejemplo, "en-US" para inglés (Estados Unidos), para acceder a la propiedad NativeName.

Así que es un poco discutible: usted pidió una región, no un idioma. Si necesita un idioma específico, solicite ese idioma, no solo una región.

Si quieres garantizar el inglés, entonces:

  1. Haga lo que Microsoft recomienda y especifique el idioma con la región: "en-US", o
  2. Use las propiedades DisplayName o DisplayName (que son en inglés incluso cuando NativeName es Cherokee).

Cuando uso este código:

var ri = new RegionInfo("us"); var nativeName = ri.NativeName; // ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ

¿por qué es nativeName la cadena "ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ" (en Cherokee )?

Si cambio a la new RegionInfo("US") (solo la diferencia, capital en US ), obtendré "United States" .

Sé que el uso preferido de RegionInfo es dar una cadena de información de cultura específica como:

new RegionInfo("en-US") new RegionInfo("chr-Cher-US")

Y así sucesivamente, y eso funciona. Pero, ¿por qué se prefiere Cherokee sobre el inglés solo si uso minúsculas?

(Visto en Windows 10 (versión 1803 "Actualización de abril de 2018"), .NET Framework 4.7.2.)

Actualización: Esto no es consistente, incluso en la misma máquina. Por ejemplo, intenté abrir PowerShell muchas veces, cada vez pegando [System.Globalization.RegionInfo]''US'' en él. Parece que durante un largo período, todas las instancias de PowerShell están dando siempre el mismo resultado. Pero luego de un tiempo, las instancias de PowerShell dan el resultado opuesto. Aquí hay una captura de pantalla de dos de las ventanas, una que tiene un nombre NativeName y la otra que tiene el opuesto. Por lo tanto, debe haber alguna determinación no determinista en marcha (no hay diferencia en la carcasa):