secuencias escape c++ unicode

escape - ¿La forma correcta de manejar Unicode con C++ en 2018?



ascii table (1)

He intentado buscar stackoverflow para encontrar una respuesta a esto, pero las preguntas y respuestas que encontré tienen alrededor de 10 años y parece que no puedo encontrar un consenso sobre el tema debido a los cambios y el posible progreso.

Hay varias bibliotecas que conozco fuera del stl que se supone que manejan Unicode

Hay algunas características de stl ( wstring , codecvt_utf8 ) que se incluyeron, pero la gente parece ser ambivalente en cuanto al uso porque tratan con UTF-16, que este sitio: ( utf-8 en todas partes ) dice que no se debe usar y mucha gente En línea parecen estar de acuerdo con la premisa.

Lo único que busco es la capacidad de hacer 4 cosas con cadenas Unicode-

  1. Leer una cadena en la memoria
  2. Busque la cadena con expresiones regulares usando unicode o ascii, concatene o realice el reemplazo / formateo de texto con ella con números o caracteres ascii + unicode.
  3. Convierta a ascii + el formato de número Unicode para los caracteres que no encajan en el rango de ascii.
  4. Escribir una cadena en el disco o enviar a donde sea.

De lo que puedo decir icu maneja esto y más. Lo que me gustaría saber es si existe una forma estándar de manejar esto en Linux, Windows y MacOS.

Gracias por tu tiempo.

Intentaré lanzar algunas ideas aquí:

  • la mayoría de los programas / programadores de C ++ simplemente asumen que un texto es una secuencia de bytes casi opaca. UTF-8 es probablemente culpable por eso, y no es sorprendente que muchos comentarios se reanuden: no te preocupes con Unicode, solo procesa cadenas codificadas en UTF-8
  • Los archivos solo contienen bytes. En un momento, si intenta procesar internamente puntos de código Unicode verdaderos, tendrá que serializar eso a bytes -> aquí nuevamente, UTF-8 gana el punto

  • Tan pronto como sales del plano bilingüe básico (puntos de código de 16 bits), las cosas se vuelven cada vez más complejas. El emoji es especialmente horrible de procesar: un emoji puede ir seguido de un selector de variación (U + FE0E VARIATION SELECTOR-15 (VS15) para texto o U + FE0F VARIATION SELECTOR-16 (VS16) para emoji-style) para modificar su visualización estilo, más o menos el antiguo i bs ^ que se utilizó en 1970 ascii cuando uno quería imprimir î . Eso no es todo, los caracteres U + 1F3FB a U + 1F3FF se usan para proporcionar un color de piel para 102 emoji humanos distribuidos en seis bloques: dingbats, emoticonos, símbolos misceláneos, símbolos y pictogramas misceláneos, símbolos y pictogramas suplementarios y transporte y mapa Simbolos

    Eso simplemente significa que hasta 3 puntos de código Unicode consecutivos pueden representar un solo glifo ... Por lo tanto, la idea de que un carácter es uno char32_t sigue siendo una aproximación

Mi conclusión es que Unicode es una cosa compleja y realmente requiere una biblioteca dedicada como ICU. Puede tratar de usar herramientas simples como los convertidores de la biblioteca estándar cuando solo se ocupa de BMP, pero el soporte completo es mucho más que eso.

Por cierto: incluso otros lenguajes como Python que pretenden tener un soporte nativo de Unicode (que es IMHO mucho mejor que el actual C ++ uno) a menudo fallan en alguna parte:

  • La biblioteca GUI de tkinter no puede mostrar ningún punto de código fuera de BMP, si bien es la herramienta IDLE estándar de Python
  • diferentes módulos o la biblioteca estándar están dedicados a Unicode además del soporte de lenguaje central (códecs y unicodedata), y otros módulos están disponibles en el Índice de Paquetes de Python como el soporte de emoji porque la biblioteca estándar no satisface todas las necesidades

Por lo tanto, el apoyo para Unicode es deficiente durante más de 10 años, y realmente no espero que las cosas vayan a ser mucho mejores en los próximos 10 años ...