¿Qué se rompería si la configuración regional C fuera UTF-8 en lugar de ASCII?

La configuración regional C no es la configuración regional predeterminada. Es un lugar que está garantizado para no causar ningún comportamiento «sorprendente». Varios comandos tienen una salida de forma garantizada (por ejemplo, ps o df encabezados, date formato) en la configuración regional C o POSIX. Para las codificaciones (LC_CTYPE), se garantiza que [:alpha:] solo contiene las letras ASCII, y así sucesivamente. Si se modificara la configuración regional C, muchas aplicaciones se comportarían mal. Por ejemplo, pueden rechazar la entrada que no es válida UTF-8 en lugar de tratarla como datos binarios.

Si desea que todos los programas de su sistema usen UTF-8, establezca la configuración regional predeterminada en UTF-8 . Todos los programas que manipulan una única codificación, es decir. Algunos programas solo manipulan flujos de bytes y no se preocupan por las codificaciones. Algunos programas manipulan múltiples codificaciones y no se preocupan por la configuración regional (por ejemplo, un servidor web o un cliente web establece o lee la codificación para cada conexión en un encabezado).

Estás un poco confundido, creo. La «configuración regional C» es una configuración regional como cualquier otra, que, como señala, es convencionalmente un sinónimo de ASCII de 7 bits.

Está integrado en la biblioteca C, supongo que la biblioteca tiene algún tipo de respaldo; no puede haber ninguna configuración regional.

Sin embargo, esto no tiene nada que ver con la forma en que los programas construidos a partir de código C manejan la entrada. La configuración regional se utiliza para traducir la entrada que se entrega a un ejecutable, que si la configuración regional del sistema es UTF-8, UTF-8 es lo que obtiene el programa independientemente de si su fuente se escribió en C o algo demás. Entonces:

Me sorprendería ver un código que solo puede manejar una entrada limpia de 7 bits y no se puede adaptar fácilmente para aceptar un UTF-8- habilitado C

Realmente no tiene sentido. Una pieza mínima de fuente C estándar que lee de la entrada estándar recibe un flujo de bytes del sistema. Si el sistema usa UTF-8 y produjo la transmisión desde algún hardware HID, esa transmisión puede contener caracteres codificados en UTF-8. Si proviene de algún otro lugar (por ejemplo, una red, un archivo), podría contener cualquier cosa, que es lo que hace que la suposición de un estándar UTF-8 sea útil.

El El hecho de que el entorno local C sea un conjunto de caracteres mucho más restringido que el entorno local UTF-8 no está relacionado. Se le llama simplemente «la configuración regional C», pero de hecho no tiene más ni menos que ver con la composición de código C que cualquier otro.

De hecho, puede codificar caracteres UTF-8 en c -cadenas en la fuente. Suponiendo que el sistema es UTF-8, esas cadenas se verán correctas cuando las use el ejecutable resultante.

El enlace «Roger Leigh» que publicaste en un comentario que creo se refiere al uso de un Conjunto expandido (UTF-8) como la configuración regional C en una biblioteca C destinada a un entorno integrado, de modo que no se deba cargar ninguna otra configuración regional para que el sistema se ocupe UTF-8.

Entonces, la respuesta a la pregunta, «¿Qué se rompería si la configuración regional de C fuera UTF-8 en lugar de ASCII?» Es, adivinar , nada, pero fuera de un entorno embebido, etc., no hay mucha necesidad de hacer esto. Pero es muy probable que se convierta en la norma en algún momento para bibliotecas como GNU C (podría serlo, creo).

Comentarios

• El comportamiento de varias llamadas al sistema está influenciado por el conjunto de caracteres de la configuración regional, por ejemplo, « isupper() no reconocerá una diéresis A (Ä) como una letra mayúscula en la configuración regional predeterminada de C. » (de man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint() es otra llamada al sistema que también está influenciada por el hecho de que C se define como solo ASCII.
• Sí, (en teoría) esas llamadas están influenciadas por configuración regional, pero esa configuración regional suele ser UTF-8, no es necesariamente ' C ' . En GNU, ' no funcionan en este sentido, sin embargo: gnu.org/software/gnulib/manual/html_node/isupper. html Tenga en cuenta que el 100% de los fundamentos de un sistema Unix están codificados en C, por lo que la idea de que " C no ' t handle UTF-8 " está bien, simplemente incorrecto y obviamente así. Si un programa escrito en C no pudiera manejar UTF-8, no habría ' no habría UTF-8 en el sistema . Período.
• Qv. también la página POSIX isupper () pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " en la configuración regional actual del proceso ", no en " la configuración regional C ". Esto también está en el estándar ISO, que se refiere a " en la configuración regional C " y " en la configuración regional actual ", generalmente en la forma " si la configuración regional actual es la configuración regional C " , etc. Recuerde, nuevamente, si está en Linux, la implementación de GNU C ' de algunas de las funciones ctype está rota.
• @gioele Estas son funciones de biblioteca, no syscalls. Las llamadas al sistema son llamadas al kernel y no se ven afectadas por las configuraciones regionales: las configuraciones regionales existen únicamente a nivel de usuario.
• @goldilocks Es ' no del todo cierto que " El 100% de los fundamentos de un sistema Unix están codificados en C ". En algún nivel, es necesario tener un poco de ensamblador, o posiblemente tipo C.Los ejemplos pueden incluir el cargador del cargador de arranque (sin error tipográfico), el proceso real de cambio de tareas y un algunas otras características similares de bajo nivel. Sin embargo, además de eso, estoy de acuerdo, es probable que se usen C (o lenguajes de nivel superior) en toda la base del código.