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 esカ, mientras que la forma de ancho medio es ｶ. El hiragana de ancho medio está incluido en Unicode y se puede usar 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 usar en computadoras modernas y se usa en algunas impresoras de recibos, tablones de anuncios eléctricos y computadoras antiguas. [2]
Los kana de ancho medio se utilizaban en los primeros tiempos 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. Los kanji de ancho medio no se utilizaban. Los caracteres kana de ancho medio no se utilizan en general en la actualidad, pero se utilizan en algunos entornos específicos, como en las pantallas de las cajas registradoras , en los recibos de las tiendas, en los subtítulos de los DVD y la televisión digital japonesa y en las 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 estrictamente se refiere solo a cómo se muestran los kana , no a cómo se almacenan , también se usa de manera imprecisa para referirse al bloque A0–DF (hexadecimal) donde se almacenan los katakana en algunas codificaciones de caracteres , 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 se pueden almacenar en estas ubicaciones, sin especificar cómo se deben mostrar; la confusión se debe a que en las primeras computadoras, los caracteres almacenados aquí se mostraban de hecho como kana de ancho medio (consulte la confusión a continuación).
Los kana de medio ancho y los kana de 2/3 de ancho se usaban desde la era anterior a la informática. [3] En la era temprana de la informática, ASCII se define como un conjunto de caracteres de 7 bits y tiene espacio para 128 caracteres. Sin embargo, dado que este estándar fue diseñado para los Estados Unidos , no contiene caracteres y símbolos, como el símbolo del yen (¥) necesario para representar la moneda japonesa, ni incluye espacio para caracteres de otros alfabetos, como kana o kanji, por lo que los caracteres japoneses no se podían codificar . Además, los caracteres japoneses, tanto kana como kanji, se dibujan en una cuadrícula cuadrada, mientras que los caracteres latinos generalmente se escriben de forma más estrecha, por lo que los caracteres japoneses tampoco se podían mostrar .
JIS X 0201 se desarrolló en 1969, una época en la que las computadoras eran generalmente incapaces, tanto por diseño de software como por recursos de hardware, de representar los miles de caracteres kanji basados en el chino que se usan en japonés. Como compromiso, este estándar codificó katakana (solamente, no hiragana ni kanji) como un pequeño conjunto de caracteres, asignados en el rango de valores de byte superior de 0x80–0xFF. Esto permitió que los procesadores de 8 bits codificaran y procesaran texto japonés fonéticamente (como katakana), aunque sin poder procesar hiragana o kanji. Estos caracteres katakana se mostraban a su vez como "kanas de ancho medio", un nuevo factor de forma poco ortodoxo y más estrecho para adaptarse al mismo ancho que los alfabetos latinos monoespaciados que las máquinas 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 ancho medio se desarrollaron como "... los primeros caracteres japoneses codificados en computadoras porque se utilizan para telegramas japoneses". [1]
El Sistema Nacional de Comunicación de Datos Bancarios (全国銀行データ通信システム) , el mayor sistema de transferencia de fondos de Japón, se estableció en 1973. Los mensajes de transacciones entre bancos solo podían utilizar latín, números y katakana de ancho medio con un máximo 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 se adaptara al área de celdas más estrecha permitida, se hicieron algunas concesiones. Por ejemplo, los signos diacríticos dakuten y handakuten se tratan como caracteres separados en lugar de ser parte del carácter precedente. Esta concesión llevó a muchos a considerar que el "kana de ancho medio" era visualmente poco atractivo y causa problemas para muchos programas informáticos actuales. [ cita requerida ]
Otro uso del kana de ancho medio es el ahorro de espacio. La versión japonesa de Windows 95 utilizó el katakana de ancho medio de MS P Gothic en su interfaz de usuario. Fue reemplazado por el kana de ancho completo de MS UI Gothic, un poco más angosto que MS P Gothic. [6] [7]
En la especificación JIS X 0201 (1969), los katakana se codifican en bloques A0–DF (hexadecimales); no se especifica cómo se muestran y no hay una codificación separada para los kana de ancho completo y de ancho medio. En JIS X 0208 , katakana, hiragana y kanji están todos 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 formato de medio ancho (por lo que los katakana JIS X 0201 se muestran en formato kana de medio ancho), mientras que JIS X 0208 se muestra en formato de ancho completo (por lo que los caracteres latinos JIS X 0208 se muestran en formato de ancho completo). Por lo tanto, en Shift JIS, los caracteres latinos y katakana tienen dos codificaciones con dos formas de visualización independientes, tanto de medio ancho 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); un bloque separado, el bloque de Formas de ancho medio y ancho completo, se utiliza para almacenar caracteres variantes, incluidos kana de ancho medio y caracteres latinos de ancho completo.
De este modo, el katakana en JIS X 0201 y la parte correspondiente de las codificaciones derivadas (la parte JIS X 0201 de Shift JIS) se muestran con 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, como se ve a continuación, 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 formularios 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 enviar 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.
El kana de ancho medio no está incluido en ISO-2022-JP: incluye el conjunto romano de JIS X 0201 y todo JIS X 0208, pero no el conjunto katakana de JIS X 0201 (que se utiliza para kana de ancho medio 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 ancho medio en ISO-2022-JP está bien definido y es una violación del formato ISO-2022-JP. Por esta razón, si se incluyera kana de ancho medio accidentalmente en un mensaje, podría volverse ilegible durante la transmisión (consulte mojibake ). El estándar de codificación WHATWG utilizado por HTML5 permite la decodificación, pero no la codificación, del katakana JIS X 0201 en ISO-2022-JP como una extensión del formato, y convierte el katakana de ancho medio a sus equivalentes JIS X 0208 al momento de 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, comprenden caracteres de 8 bits. Como alternativa, 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 de computadora 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 del carácter debe especificarse con un encabezado de respuesta HTTP o una etiqueta Meta .
En sentido estricto, la codificación JIS X 0201 como "katakana de ancho medio" es incorrecta, ya que la norma no define el ancho de los caracteres, sino solo la representación en código de los caracteres katakana. En la norma JIS X 0201, los caracteres katakana se imprimen en ancho normal (completo), no en ancho medio.
Los caracteres de medio ancho solo se usaron para visualización durante el período en que los caracteres se mostraban con 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 generalizaran. Sin embargo, en el estándar Shift JIS, que combina el estándar JIS X 0201 (cuyos caracteres –latinos y katakana– se mostraban en ancho medio) y el estándar JIS X 0208 (cuyos caracteres –katakana, hiragana, kanji y latinos– se mostraban 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 en qué sección se encuentren (0201 o 0208); por lo tanto, el bloque katakana 0201 puede considerarse como correspondiente a "kana de ancho medio", y el malentendido de que el estándar 0201 define caracteres de "ancho medio" está muy extendido.
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 hay conexión entre el número de bytes y el ancho (excepto los correspondientes en Shift JIS, como se indicó anteriormente); por ejemplo, Unicode se puede codificar con cuatro bytes ( UTF-32 ) para mostrar caracteres de ancho completo y de ancho simple.
