Pregunta

Me gustaría tener un lugar canónico para agrupar información sobre el soporte Unicode en varios idiomas. ¿Es parte del lenguaje central? ¿Se proporciona en bibliotecas? ¿No está disponible en absoluto? ¿Existe un recurso popular para la información Unicode en un idioma? Un idioma por respuesta por favor. Además, si pudiera convertir el idioma en un encabezado que lo hiciera más fácil de encontrar.

No hay solución correcta

Otros consejos

Perl

Perl tiene soporte incorporado para Unicode, principalmente. Más o menos. Desde perldoc:

  • perlunitut - Tutorial sobre el uso de Unicode en Perl. Enseña en gran medida en términos absolutos sobre lo que debe y no debe hacer en lo que respecta a Unicode. Fundamentos básicos.
  • perlunifaq - Preguntas frecuentes sobre Unicode en Perl.
  • perluniintro - Introducción a Unicode en Perl. Menos "predicación" que perlunitut .
  • perlunicode - Para cuando absolutamente tienes que saber todo lo que hay que saber sobre Unicode y Perl .

Python 3k

Python 3k (o 3.0 o 3000) tiene un nuevo enfoque para manejar texto (unicode) y datos:
Texto vs. Datos en lugar de Unicode vs. 8 bits . Consulte también Unicode HOWTO .

Java

Igual que con .NET, Java usa UTF-16 internamente: java.lang.String

  

Una String representa una cadena en el formato UTF-16 en la que los caracteres suplementarios están representados por pares sustitutos (consulte la sección Representaciones de caracteres Unicode en el Carácter para más información). Los valores de índice se refieren a unidades de código char , por lo que un carácter suplementario usa dos posiciones en una String .

HQ9 +

El comando Q tiene soporte completo de Unicode en la mayoría de las implementaciones.

Delphi

Delphi 2009 es totalmente compatible con Unicode. Han cambiado la implementación de string por defecto a la codificación Unicode de 16 bits, y la mayoría de las bibliotecas, incluidas las de terceros, admiten Unicode. Vea Delphi y Unicode .

de Marco Cant & # 249;

Antes de Delphi 2009, el soporte para Unicode era limitado, pero había WideChar y WideString para almacenar la cadena codificada de 16 bits. Consulte Unicode en Delphi para obtener más información.

Tenga en cuenta que aún puede desarrollar una aplicación bilingüe CJKV sin usar Unicode. Por ejemplo, la cadena codificada Shift JIS para japonés se puede almacenar usando AnsiString simple .

Go

El Lenguaje de programación Go es compatible con Unicode y funciona con UTF-8.

Python

Python 2 tiene las clases str y unicode . Los objetos str almacenan bytes, los objetos unicode almacenan caracteres UTF-16. La mayoría de las funciones de la biblioteca admiten ambas (p. Ej., os.listdir ('.') devuelve una lista de str , os.listdir (u '.') devuelve una lista de objetos unicode ). Ambos tienen métodos encode y decode .

Python 3 básicamente cambió el nombre de unicode a str . El Python 3 equivalente a str sería el tipo bytes . bytes tiene un decode y str un método encode . Dado que los objetos Python 3.3 str utilizan internamente uno de varias codificaciones para ahorrar memoria. Para un programador de Python, todavía parece una secuencia abstracta Unicode.

Python admite:

  • codificación / decodificación
  • normalización
  • conversión simple de casos y división en espacios en blanco
  • buscando caracteres por su nombre

Python no admite / tiene compatibilidad limitada para:

  • colación (limitada)
  • conversiones de mayúsculas y minúsculas donde no hay mapeo 1: 1 entre mayúsculas y minúsculas
  • expresiones regulares ( se trabajó en )
  • segmentación de texto
  • manejo de texto bidireccional

Consulte también: La verdad sobre Unicode en Python

JavaScript

Parece que antes de JS 1.3 no había soporte para Unicode. A partir de 1.5, UTF-8, UTF-16 y UCS-2 son compatibles. Puede usar secuencias de escape Unicode en cadenas, expresiones regulares e identificadores. Fuente

.NET (C #, VB.NET, ...)

.NET almacena cadenas internamente como una secuencia de System.Char objetos. Un System.Char representa una unidad de código UTF-16 .

De la documentación de MSDN en System.Char :

  

.NET Framework utiliza el Char   estructura para representar un Unicode   personaje. El estándar Unicode   identifica cada carácter Unicode con   un número escalar único de 21 bits llamado   punto de código, y define el UTF-16   formulario de codificación que especifica cómo un   el punto de código se codifica en una secuencia   de uno o más valores de 16 bits. Cada   El valor de 16 bits varía de hexadecimal   0x0000 a 0xFFFF y se almacena en   una estructura Char .

Recursos adicionales:

Tcl

Las cadenas Tcl han sido secuencias de caracteres Unicode desde Tcl 8.1 (1999 ) Internamente, se transforman dinámicamente entre UTF-8 (estrictamente el mismo UTF-8 modificado como Java debido al manejo de caracteres U + 00000 ) y UCS-2 (en host endianness y BOM, por supuesto). Todas las cadenas externas (con una excepción), incluidas las utilizadas para comunicarse con el sistema operativo, son internamente Unicode antes de transformarse en cualquier codificación que se requiera para el host (o que se configure manualmente en un canal de comunicaciones). La excepción es cuando los datos se se copian entre dos canales de comunicaciones con una codificación común (y algunas otras restricciones no relevantes aquí) donde se utiliza una transferencia binaria directa sin copia.

Los caracteres fuera del BMP no se manejan actualmente ni interna ni externamente. Este es un problema conocido.

Esquema R6RS

Requiere la implementación de Unicode 5.1. Todas las cadenas están en 'formato unicode'.

Óxido

Las

cadenas de Rust ( std :: String y & amp; str ) siempre son válidas UTF-8, y no usan terminadores nulos, y como resultado no pueden ser indexados como una matriz, como si pudieran estar en C / C ++, etc. Se pueden dividir algo así como Ir usando .get desde 1.20, con la advertencia de que fallará si intenta cortar el medio de un punto de código.

Rust también tiene OsStr / OsString para interactuar con el sistema operativo host. Es una matriz de bytes en Unix (que contiene cualquier secuencia de bytes). En Windows es WTF-8 (un superconjunto de UTF-8 que maneja las cadenas Unicode mal formadas que están permitidas en Windows y Javascript), & amp; str y String se puede convertir libremente a OsStr o OsString , pero requieren controles para encubrirlo de otra manera. Fallando en unicode inválido o reemplazándolo con el carácter de reemplazo Unicode. (También hay Path / PathBuf , que son solo envoltorios alrededor de OsStr / OsString ).

También existen los tipos CStr y CString , que representan cadenas C terminadas en Nulo, como OsStr en Unix, pueden contener bytes arbitrarios.

Rust no es compatible directamente con UTF-16. Pero puede convertir OsStr a UCS-2 en Windows.

Common Lisp (SBCL y CLisp)

Según esto , SBCL y CLisp admiten Unicode.

Objetivo-C

Ninguno incorporado, aparte de lo que esté disponible como parte de la biblioteca de cadenas C.

Sin embargo, una vez que agregue marcos ...

Foundation (Cocoa and Cocoa Touch) y Core Foundation

NSString y CFString implementan una clase de cadena totalmente basada en Unicode (en realidad, varias clases, como detalle de implementación). Los dos tienen un "puente gratuito" para que la API de uno se pueda usar con instancias del otro, y viceversa.

Para datos que no necesariamente representan texto, hay NSData y CFData. NSString proporciona métodos y CFString proporciona funciones para codificar texto en datos y decodificar texto a partir de datos. Core Foundation admite más de cien codificaciones diferentes, incluidas todas las formas de UTF. Las codificaciones se dividen en dos grupos: codificaciones incorporadas , que son compatibles en todas partes, y codificaciones externas , que al menos son compatibles con Mac OS X.

NSString proporciona métodos para normalizar a las formas D, KD, C o KC. Cada uno devuelve una nueva cadena.

Tanto NSString como CFString proporcionan una amplia variedad de opciones de comparación / clasificación. Aquí hay Indicadores de opciones de comparación de la Fundación y Indicadores de opciones de comparación de Core Foundation . No todos son sinónimos; por ejemplo, Core Foundation hace que la comparación literal (basada en puntos estrictos de código) sea la predeterminada, mientras que Foundation hace que la comparación no literal (permitiendo que los caracteres con acentos se comparen de manera igual) es la predeterminada.

Tenga en cuenta que Core Foundation no requiere Objective-C; de hecho, fue creado para proporcionar la mayoría de las características de los programadores de Foundation a Carbon, que usaban C o C ++. Sin embargo, sospecho que el uso más moderno es en los programas Cocoa o Cocoa Touch, todos escritos en Objective-C u Objective-C ++.

C / C ++

C

C antes de C99 no tiene soporte Unicode integrado. Utiliza conjuntos de caracteres terminados en cero ( char * o char [] ) como cadenas. Un char se especifica mediante un byte (8 bits).

C99 especifica las funciones wcs además de las antiguas funciones str (por ejemplo, strlen - > wcslen ). Estas funciones toman wchar_t * en lugar de char * . wchar_t significa tipo de carácter ancho. El tamaño de wchar_t es específico del compilador y puede ser tan pequeño como 8 bits. Si bien los diferentes compiladores usan diferentes tamaños, generalmente son de 16 bits (UTF-16) o de 32 bits (UTF-32).

La mayoría de las funciones de la biblioteca C son transparentes para UTF-8. P.ej. si su sistema operativo es compatible con UTF-8 (y UTF-8 está configurado como el conjunto de caracteres de su sistema), al crear un archivo usando fopen que pase una cadena codificada UTF-8 se creará un archivo con el nombre correcto.

C ++

La situación en C ++ es muy similar ( std :: string - > std :: wstring ), pero al menos hay esfuerzos para obtener algún tipo de < a href = "http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3572.html" rel = "nofollow noreferrer"> soporte unicode en la biblioteca estándar .

D

D soporta UTF-8, UTF-16 y UTF-32 (char, wchar y dchar, respectivamente). La tabla con todos los tipos se puede encontrar aquí .

PHP

Ya hay un hilo completo sobre esto en SO!

Rubí

Lo único que puedo encontrar para Ruby es bastante viejo y no es un gran rubista, no estoy seguro de cuán preciso sea.

  

Para el registro, Ruby admite utf8, pero no multibyte. Internamente, generalmente supone que las cadenas son vectores de bytes, aunque hay bibliotecas y trucos que generalmente puede usar para que las cosas funcionen.

Se encontró que aquí .

Ruby 1.9

Ruby 1.9 adjunta codificaciones a cadenas. Las cadenas binarias usan la codificación ASCII-8BIT. Si bien la codificación predeterminada suele ser UTF-8 en cualquier sistema moderno, no se puede suponer que todas las funciones de biblioteca de terceros siempre devuelven cadenas en esta codificación. Puede devolver cualquier otra codificación (por ejemplo, algunos analizadores de yaml lo hacen en algunas situaciones). Si concatena dos cadenas de codificación diferente, podría obtener un Encoding :: CompatibilityError .

Arc

Arc no tiene ningún soporte Unicode. Sin embargo .

Lua

Lua 5.3 tiene una biblioteca utf8 incorporada, que maneja la codificación UTF-8. Le permite convertir una serie de puntos de código a la secuencia de bytes correspondiente y viceversa, obtener la longitud (el número de puntos de código en una cadena), iterar sobre los puntos de código en una cadena, obtener la posición de byte del n th punto de código. También proporciona un patrón, para ser utilizado por las funciones de coincidencia de patrones en la biblioteca string , que coincidirá con una secuencia de bytes UTF-8.

Lua 5.3 tiene secuencias de escape de punto de código Unicode que se pueden utilizar en literales de cadena (por ejemplo, " \ u {61} " para " a " ) Se traducen a secuencias de bytes UTF-8.

El código fuente de Lua se puede codificar en UTF-8 o en cualquier codificación en la que los caracteres ASCII ocupen un byte. UTF-16 y UTF-32 no son entendidos por el intérprete Lua de vainilla. Pero las cadenas pueden contener cualquier codificación o datos binarios arbitrarios.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top