Los kana de ancho medio (半角カナ, Hankaku kana ) son caracteres katakana que se muestran comprimidos a la mitad de su ancho normal (una relación de aspecto de 1:2 ), en lugar de la relación de aspecto cuadrada habitual (1:1). Por ejemplo, la forma habitual (de ancho completo) del katakana ka es カ, mientras que la forma de medio ancho es ｶ. El hiragana de ancho medio está incluido en Unicode y se puede utilizar en la Web o en libros electrónicos a través de CSS confont-feature-settings: "hwid" 1 fuentes OpenType basadas en Adobe-Japan1-6 . [1] El kanji de ancho medio se puede utilizar en computadoras modernas y en algunas impresoras de recibos, tableros de anuncios eléctricos y computadoras antiguas. [2]
Los kana de ancho medio se utilizaron en los primeros días de la informática japonesa para permitir que los caracteres japoneses se mostraran en la misma cuadrícula que las fuentes monoespaciadas de caracteres latinos. No se utilizaron kanji de ancho medio. Los caracteres kana de ancho medio no se utilizan generalmente hoy en día, pero encuentran algún uso en entornos específicos, como pantallas de cajas registradoras , recibos de tiendas, subtítulos de DVD y televisión digital japonesa y etiquetas de direcciones postales. Su uso es a veces también una elección estilística, particularmente frecuente en cierta jerga de Internet .
El término "kana de ancho medio", que se refiere estrictamente sólo a cómo se muestran los kana , no a cómo se almacenan , también se usa libremente para referirse al bloque A0–DF (hexadecimal) donde los katakana se almacenan en algunas codificaciones de caracteres , como como JIS X 0201 (1969); consulte las codificaciones a continuación. Sin embargo, esto es formalmente incorrecto: este estándar JIS simplemente especifica que los katakana pueden almacenarse en estas ubicaciones, sin especificar cómo deben mostrarse; la confusión se debe a que en los primeros tiempos de la informática, los caracteres almacenados aquí se mostraban en realidad como kana de medio ancho (consulte la confusión a continuación).
La kana de medio ancho y la kana de 2/3 de ancho se utilizaron desde la era anterior a la computadora. [3] En los inicios de la era informática, ASCII se definía como un conjunto de caracteres de 7 bits y tenía espacio para 128 caracteres. Sin embargo, dado que este estándar fue diseñado para los Estados Unidos , no contiene caracteres ni símbolos, como el símbolo yen (¥) necesario para representar la moneda japonesa, ni incluye espacio para caracteres de otros alfabetos, como kana o kanji. – por lo tanto, no se pudieron codificar los caracteres japoneses . Además, los caracteres japoneses, tanto kana como kanji, se dibujan en una cuadrícula, mientras que los caracteres latinos generalmente se escriben de forma más estrecha, por lo que tampoco se pueden mostrar los caracteres japoneses .
JIS X 0201 se desarrolló en 1969, una época en la que las computadoras eran generalmente incapaces, tanto por el diseño de software como por los recursos de hardware, de representar los miles de caracteres kanji chinos utilizados en japonés. Como compromiso, este estándar codificaba katakana (solamente, no hiragana ni kanji) como un pequeño conjunto de caracteres, asignados en el rango de valores de bytes superiores de 0x80–0xFF. Esto permitió a los procesadores de 8 bits codificar y procesar texto japonés fonéticamente (como katakana), aunque sin poder procesar hiragana o kanji. Estos caracteres katakana se mostraban a su vez como "kana de medio ancho", un factor de forma nuevo, poco ortodoxo y más estrecho para adaptarse al mismo ancho que las máquinas de alfabetos latinos monoespaciados eran capaces de imprimir y mostrar. En cuanto a la codificación, JIS X 0201 es una extensión variante de ASCII: incluye caracteres adicionales y no coincide exactamente con ASCII en la parte superpuesta (la sección de caracteres latinos).
Los kana de medio ancho se desarrollaron como "... los primeros caracteres japoneses codificados en computadoras porque se usan para telegramas japoneses". [1]
El Sistema Nacional de Comunicación de Datos Bancarios (全国銀行データ通信システム) , el sistema de transferencia de fondos más grande de Japón, se estableció en 1973. Los mensajes de transacciones entre bancos solo podían usar latín, números y katakana de medio ancho dentro de 20 caracteres. El sistema fue reemplazado por ZEDI (Sistema Nacional de Intercambio Electrónico de Datos Bancarios) en 2018, que puede manejar hiragana y kanji con caracteres de longitud variable. [4] [5]
Para que el katakana encajara en el área de celda más estrecha permitida, se hicieron algunos compromisos. Por ejemplo, los signos diacríticos dakuten y handakuten se tratan como caracteres separados en lugar de ser parte del carácter anterior. Este compromiso llevó a muchos a considerar el "kana de medio ancho" visualmente poco atractivo y causa problemas a muchos programas informáticos actuales. [ cita necesaria ]
Otro uso de la kana de medio ancho es ahorrar espacio. La versión japonesa de Windows 95 utilizaba katakana de ancho medio de MS P Gothic en su interfaz de usuario. Fue reemplazado por kana de ancho completo de MS UI Gothic, un poco más estrecho que MS P Gothic. [6] [7]
En la especificación JIS X 0201 (1969), los katakana están codificados en el bloque A0-DF (hexadecimal); no se especifica cómo se muestran y no existe una codificación separada para kana de ancho completo y medio ancho. En JIS X 0208 , katakana, hiragana y kanji están codificados (y se muestran como caracteres de ancho completo; no hay caracteres de ancho medio), aunque el orden de los kana es diferente; consulte JIS X 0208#Hiragana y katakana .
En Shift JIS , que combina JIS X 0201 y JIS X 0208, estas codificaciones (ambas pueden codificar caracteres latinos y katakana) se almacenan por separado, y JIS X 0201 se muestra en tamaño medio (por lo tanto, los katakana JIS X 0201 son se muestran como kana de ancho medio), mientras que JIS X 0208 se muestran todos en ancho completo (por lo tanto, todos los caracteres latinos JIS X 0208 se muestran como caracteres latinos de ancho completo). Por lo tanto, en Shift JIS, los caracteres latinos y katakana tienen dos codificaciones con dos formas de visualización separadas, tanto de ancho medio como de ancho completo.
En Unicode , katakana e hiragana se utilizan principalmente como caracteres normales de ancho completo (los bloques Katakana e Hiragana se muestran como caracteres de ancho completo); Como bloque separado, el bloque Formas de ancho medio y ancho completo se utiliza para almacenar caracteres variantes, incluidos caracteres kana de ancho medio y caracteres latinos de ancho completo.
Por lo tanto, el katakana en JIS X 0201 y la parte correspondiente de las codificaciones derivadas (la parte JIS X 0201 de Shift JIS) se muestran como de medio ancho, mientras que en Unicode las formas de medio ancho se especifican por separado.
"J" indica los primeros cuatro bits en JIS X 0201 (aunque ver más abajo, estos no necesariamente indican la mitad del ancho) y en otros conjuntos como Shift JIS , "U" indica la fila en Unicode en el bloque de formas de ancho medio y ancho completo .
Tenga en cuenta que la primera celda en blanco representa un carácter inexistente en JIS, A0; pero un paréntesis doble de ancho completo ｠ en Unicode, U+FF60.
Dado que los protocolos SMTP y NNTP (utilizados para entregar correo electrónico y Usenet , respectivamente) anteriormente solo podían transmitir bytes de 7 bits, la convención era utilizar ISO-2022-JP para enviar correo electrónico en japonés.
La kana de medio ancho no está contenida en ISO-2022-JP: incluye el conjunto romano de JIS X 0201 y todo JIS X 0208, pero no el conjunto de katakana de JIS X 0201 (que se usa para kana de medio ancho en Shift JIS, por ejemplo). Ambos conjuntos de JIS X 0201 tienen códigos ISO 2022, pero el perfil ISO-2022-JP solo incluye el conjunto romano: esto significa que el formato para incluir katakana de medio ancho en ISO-2022-JP está bien definido y es una violación. del formato ISO-2022-JP. Por esta razón, si se incluyera accidentalmente kana de medio ancho en un mensaje, podría resultar confuso durante la transmisión (ver mojibake ). El estándar de codificación WHATWG utilizado por HTML5 permite decodificar, pero no codificar, de katakana JIS X 0201 en ISO-2022-JP como una extensión del formato, y convierte katakana de medio ancho a sus equivalentes JIS X 0208 tras la codificación. [8]
Esto ya no es un problema ya que la mayoría de los servidores de correo electrónico actuales admiten la extensión 8BITMIME y, por lo tanto, entienden caracteres de 8 bits. Alternativamente, se puede utilizar un sistema de codificación como Base64 y especificarlo en el mensaje mediante MIME .
El problema que existe en el correo electrónico no existe con las páginas web ya que HTTP acepta caracteres de 8 bits.
Sin embargo, un problema que existe es que los programas informáticos tienen dificultades para determinar si deben tratar un carácter como Shift JIS , EUC-JP o UTF-8 ; por lo tanto, la información del código de carácter debe especificarse con un encabezado de respuesta HTTP o una metaetiqueta .
Estrictamente hablando, la codificación JIS X 0201 como "katakana de ancho medio" es incorrecta, ya que el estándar no define el ancho de los caracteres, solo define la representación del código de los caracteres katakana. En el estándar JIS X 0201, los caracteres katakana se imprimen en ancho normal (completo), no en la mitad del ancho.
Los caracteres de ancho medio solo se usaban para visualización durante el período en el que los caracteres se mostraban a medio ancho (y se usaban codificaciones de un solo byte), antes de que las visualizaciones de caracteres de ancho completo (y las codificaciones de doble byte asociadas, como JIS X 0208) se convirtieran en generalizado. Sin embargo, en el estándar Shift JIS, que combina el estándar JIS X 0201 (cuyos caracteres (latín y katakana) se mostraban en la mitad del ancho) y el estándar JIS X 0208 (cuyos caracteres (katakana, hiragana, kanji y latín) se (se muestran en ancho completo), los caracteres katakana y latinos se codifican dos veces, tanto en JIS X 0201 como en JIS 0208, pero se muestran en ancho medio o ancho completo según la sección en la que se encuentren (0201 o 0208); por lo tanto, 0201 Se puede considerar que el bloque katakana corresponde a un "kana de medio ancho", y está muy extendido el malentendido de que el estándar 0201 define caracteres de "medio ancho".
Además, aunque JIS X 0201 es una codificación de un solo byte (y se muestra en la mitad del ancho) y JIS X 0208 es una codificación de doble byte (y se muestra en el ancho completo), no existe ninguna conexión entre el número de bytes y el ancho ( distintos de los correspondientes en Shift JIS, como se muestra arriba); por ejemplo, Unicode se puede codificar con cuatro bytes ( UTF-32 ) para mostrar caracteres de ancho completo y de ancho único.
