O que seria quebrado se a localidade C fosse UTF-8 em vez de ASCII?

Question

A localidade C é definida para usar o conjunto de caracteres ASCII e o POSIX não fornece uma maneira de usar um conjunto de caracteres sem alterar a localidade também.

O que aconteceria se a codificação de C fosse trocada para UTF-8?

O lado positivo seria que o UTF-8 se tornaria o conjunto de caracteres padrão para qualquer processo, mesmo os daemons do sistema. Obviamente, haveria aplicativos que quebrariam porque eles supõem que C usa ASCII de 7 bits. Mas essas aplicações realmente existem? Neste momento, um monte de código escrito é localmente e com reconhecimento de charset até certo ponto, eu ficaria surpreso em ver código que pode somente lidar com entradas limpas de 7 bits e não pode ser facilmente adaptado para aceitar um C habilitado para UTF-8.

    

Answer 1

A localidade C não é a localidade padrão. É uma localidade garantida que não causa nenhum comportamento “surpreendente”. Um número de comandos tem a saída de um formulário garantido (por exemplo, ps ou df headers, date format) no C ou POSIX locale. Para codificações ( LC_CTYPE ), é garantido que [:alpha:] contém apenas as letras ASCII e assim por diante. Se o C locale foi modificado, isso chamaria muitos aplicativos para se comportarem mal. Por exemplo, eles podem rejeitar a entrada que é UTF-8 inválida em vez de tratá-la como dados binários.

Se você quiser que todos os programas em seu sistema usem UTF-8, defina a localidade padrão como UTF-8. Todos os programas que manipulam uma única codificação, isto é. Alguns programas apenas manipulam fluxos de bytes e não se importam com codificações. Alguns programas manipulam várias codificações e não se importam com a localidade (por exemplo, um servidor da Web ou um cliente Web define ou lê a codificação de cada conexão em um cabeçalho).

    

Answer 2

Você está um pouco confuso, eu acho. A "localidade C" é uma localidade como qualquer outra, que, como você aponta, é convencionalmente um sinônimo de ASCII de 7 bits.

Ele está embutido na biblioteca C, suponho que a biblioteca tenha algum tipo de fallback - não pode haver nenhum locale.

No entanto, isso não tem nada a ver com a maneira como os programas construídos a partir do código C lidam com a entrada. A localidade é usada para traduzir a entrada que é para um executável, que se a localidade do sistema for UTF-8, UTF-8 é o que o programa obtém independentemente de sua origem ter sido escrita em C ou algo outro. Então:

I would be surprised to see code that can only deal with 7-bit clean input and cannot be easily adapted to accept a UTF-8-enabled C

Realmente não faz sentido. Uma parte mínima da fonte C padrão que lê a entrada padrão recebe um fluxo de bytes do sistema. Se o sistema usar UTF-8 e produzir o fluxo a partir de algum hardware HID, esse fluxo poderá conter caracteres codificados em UTF-8. Se vier de algum outro lugar (por exemplo, uma rede, um arquivo), ele pode conter qualquer coisa, o que torna a suposição de um padrão UTF-8 útil.

O fato de o código do idioma C ser um conjunto de caracteres muito mais restrito que o código do idioma UTF-8 não está relacionado. É chamado apenas de "o local C", mas na verdade não tem mais ou menos a ver com a composição do código C do que qualquer outro.

Você pode, de fato, codificar caracteres UTF-8 em strings C na origem. Presumindo que o sistema é UTF-8, essas strings parecerão corretas quando usadas pelo executável resultante.

O link "Roger Leigh" que você postou em um comentário que acredito se refere ao uso de um conjunto expandido (UTF-8) como localidade C em uma biblioteca C destinada a um ambiente incorporado, nenhum outro local deve ser carregado para o sistema para lidar com o UTF-8.

Então a resposta para a pergunta, "O que quebraria se a localidade C fosse UTF-8 em vez de ASCII?" é, eu adivinharia , nada, mas fora de um ambiente incorporado, etc. não há muita necessidade de fazer isso. Mas muito provavelmente isso se tornará a norma em algum momento para bibliotecas como o GNU C (pode muito bem ser, eu acho).