Suponga que desea almacenar la configuración regional de la preferencia del usuario en la base de datos, ¿qué valor usará?en_US o en-US, ¿cuál debería usar?
en_US o es-
Se trata de dos normas, pero que uno prefiere utilizar como parte de su propia aplicación?
Actualizado: parece que muchos sitios web usan el guión en lugar del guión bajo, p. Ej.
http://zh.wikipedia.org/zh-tw http://www.google.com.hk/search?hl=zh-TW
Espera, espera, espera. Chicos, estoy bastante seguro "-" es el estándar. Si ve "_" en algún lugar, es probable que haya sido ideado por algunas personas para que sea un identificador válido.
Personalmente iría con "-", solo para ser correcto.
en_US. This es una lectura muy útil.
Lamentablemente, Oracle ha eliminado o movido ese artículo. –
Sí, lo siento, votando a medida que el artículo se va. – ebruchez
@ebruchez en lugar de votar abajo, solo puede dejar un comentario y puedo actualizar el enlace o eliminar la respuesta. Esta es una respuesta de 2 años y medio de edad. Gracias por atraparlo sin embargo. – CoolBeans
No creo que en-US sea un estándar para Java. (Si lo ves en alguna parte, podrías agregar un enlace).
Tan solo use en_US.
Como se muestra, hay muchas variantes, pero la el estándar oficial es subrayado. Al realizar llamadas a marcos con diferentes convenciones, tiene un "pratfall" del codificador que necesita saber que se requiere una conversión. recomendamos usar la convención del marco desde el que llama. Cuando realiza llamadas a otro marco, proporcione "proxies" que realicen la conversión. ¿Por qué? elimina la necesidad de saber que el marco llamado usa una convención diferente. Los colaboradores SÓLO "verán" una convención usando eso evitará la pratfall. – DaBlick
Si está trabajando con Java, también puede usar Java locale format (en_US).
Los documentos BCP 47 realmente hacen especificar el formato en-US, y es tan común si no es más común que los nombres de configuración regional al estilo de Java. Pero en la práctica verás un poco la forma con la barra inferior. Por ejemplo, tanto Java como most POSIX-type platforms usan la barra inferior para su separador de idioma/región.
Así que no puedes equivocarte mucho con cualquiera de las opciones. Pero dado que está escribiendo en Java y probablemente apuntando a una plataforma Unix, en_US es probablemente el camino a seguir.
Personalmente ni siquiera recuerdo haber visto la versión de guión bajo en uso. Aunque no trabajo mucho con Java. –
Sí, pero tiene una etiqueta 'java' en su pregunta. Revisa los enlaces en mi respuesta, si quieres ... – dkarp
Hum, bueno, tienes razón sobre las plataformas * nix al menos. Olvidé esos. –
En Java 7, hay un método nuevo Locale.forLanguageTag(String), que asume el guión como separador. Lo consideraría como normativo.
Consulte la documentación de Locale para obtener más información.
Sí, "-" es el estándar, incluso si uso Java, seguiré el estándar. (http://www.w3.org/TR/html401/struct/dirlang.html) – Howard
@Howard Um, vas a necesitar los nombres de configuración regional en formato 'en_US' cada vez que crea una instancia de un objeto' Locale'. (Para formato de moneda, formato de fecha, etc.) Almacenar los datos en el formato 'en-US' y reemplazar guiones con guiones bajos cada vez que necesite usar los datos almacenados funcionará * absolutamente *, pero puede ser más inteligente (y ciertamente más simple) para almacenar los nombres de configuración regional en el formato que su aplicación realmente usa ... – dkarp
@dkarp Usando [Locale # toLanguageTag()] (http://docs.oracle.com/javase/7/docs/api/java/util /Locale.html#toLanguageTag()) y [Locale # forLanguageTag()] (http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#forLanguageTag (java.lang. String)) hará el truco (en JDK 1.7, sin embargo). – viphe