android unicode localization cjk

Caracteres japoneses que parecen chinos en Android



unicode localization (2)

PREÁMBULO: desde API 17 (Android 4.2), hay un método TextView.setTextLocale() que resuelve explícitamente este problema para TextViews y clases derivadas. Asigne una configuración regional japonesa ( Locale.JAPAN ) y los caracteres Unihan se verán en japonés.

Tengo una aplicación en Android que muestra texto en japonés en WebViews y TextViews. Hay algunos caracteres chinos (kanji) que se ven, por convención, de manera diferente en China y en Japón, pero comparten el mismo punto de código Unicode. Normalmente, el navegador se basaría en la etiqueta lang para elegir el glifo correcto. En Android, todos adoptan de forma predeterminada sus formas chinas, y quiero formas japonesas.

El problema está bien explicado en este artículo . Este artículo también sirve como una ilustración perfecta del problema: cuando se mira en Android (hasta 2.2), los caracteres en los "Ejemplos de caracteres dependientes del idioma" tienen el mismo aspecto y el chino.

Usar el atributo lang="ja" no ayuda. Cambiar la configuración regional del sistema completo a japonés tampoco ayuda.

Me pregunto acerca de los teléfonos Android que se venden en Japón. ¿Los caracteres como 直, 今, 化 también parecen de estilo chino? Estoy asumiendo que no.

Entonces las preguntas son: ¿hay imágenes oficiales de Android por ahí? ¿Puedo obtener uno para ejecutar en el emulador? ¿Sigue siendo la fuente DroidSansFallback la única fuente compatible con CJK en esos? Y si lo es, ¿es lo mismo que en el vanilla USA USA?

Estoy esperando que los glifos japoneses estén escondidos en algún lugar de la fuente (área privada Unicode o algo así). Si es así, podría aprovecharlos ...

EDITAR: localizó DroidSansJapanese.ttf, lo instaló en el emulador copiando en / system / fonts, reinició. No hizo ninguna diferencia en el aspecto del artículo de Unihan. Incluso el área de sugerencia de la entrada de texto en japonés (que debería saberse mejor) se muestra como en chino.

¿Cómo sé el tipo de letra del DroidSansJapanese.ttf? Tengo la sensación de que todavía es Droid Sans, lo mismo que en la fuente incorporada DroidSansFallback. Pero si contienen el mismo tipo de letra, ¿qué gobierna cuál debería tener prioridad? Uno pensaría: sistema local, pero aparentemente no. Las fuentes en Android se instalan solo copiando, ¿verdad?


Encontré una solución algo tumultuosa.

La fuente DroidSansJapanese.ttf existe y está disponible para su descarga, por ejemplo, here . Lo descargué, lo renombré a DroidSansJapanese.mp3 para evitar el límite de 1MB de activos comprimidos y lo coloqué en assets/web . Luego introduje la siguiente declaración de CSS:

@font-face { font-family: "DroidJP"; src:url(''DroidSansJapanese.mp3'') }

Luego agregué ''DroidJP'' a la font-family de font-family de cada estilo CSS relevante. La forma en que cargo mi HTML, la carpeta assets/web ya está designada como la base para cargar contenido vinculado.

Tras un examen cuidadoso, encontré varios lugares en la aplicación donde el japonés estaba en TextView . Para aquellos, he cargado la tipografía de esta manera:

Typeface s_JFont = Typeface.createFromAsset(Ctxt.getAssets(), "web/DroidSansJapanese.mp3");

y llamado setTypeface() en cada TextView relevante. ¡Ahora para PROFIT!

Esto expandió mi APK en aproximadamente 1 MB. Había una manera alternativa, donde almacenaba la fuente en los activos en forma comprimida, eso me ahorraría unos 500 KB de tamaño APK, pero luego tendría que expandirlo a la memoria del teléfono en la primera ejecución, preocupación acerca de la ruta de la carpeta de datos y pierde compatibilidad con Android 1.5.

Algo de crédito es debido: here y here . No funciona en Android 2.1 (las WebViews, no las TextViews): es un error conocido .

Ahora, la pregunta sigue siendo: ¿cómo identifico los dispositivos donde la fuente predeterminada ya contiene las formas japonesas?

EDITAR re: el truco de mp3. Implementé la solución fragmentada al principio, pero luego decidí ir con la fuente en los activos. El enfoque fragmentado tiene un lado positivo, un tamaño de APK más pequeño, y las siguientes desventajas:

  • Consume más memoria del teléfono: termina almacenando tanto la fuente comprimida en los activos como descomprimida en el directorio de datos
  • Es incompatible con Android 1.5 en el lado de TextView: el método Typeface.createFromFile() se introdujo en el nivel de API 4
  • Complica la generación de HTML: el CSS con la declaración @ font-face necesita ser parametrizado, ya que la ruta de datos es una variable
  • Disminuye el inicio de la primera aplicación: gastas tiempo combinando los fragmentos

Tampoco es una opción almacenar la fuente como un elemento comprimido: la fuente no se muestra en WebView, y puede ver claramente en LogCat el mensaje "Los datos superan UNCOMPRESS_DATA_MAX".


Hay fuentes con soporte japonés completo. Escuché a algunas personas hablar sobre DroidSansJapanese.tff y TakaoPGothic.