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

A localidade C não é o local padrão. É um local que não causa nenhum comportamento “surpreendente”. Vários comandos têm saída de forma garantida (por exemplo, ps ou df cabeçalhos, date formato) na localidade C ou POSIX. Para codificações (LC_CTYPE), é garantido que [:alpha:] contém apenas as letras ASCII e assim por diante. Se a localidade C fosse modificada, muitos aplicativos teriam um comportamento incorreto. Por exemplo, eles podem rejeitar a entrada que é UTF-8 inválida em vez de tratá-la como dados binários.

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

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

É embutido na biblioteca C, suponho que o a biblioteca tem algum tipo de reserva – não pode haver localidade.

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

Eu ficaria surpreso em ver um código que só pode lidar com entrada limpa de 7 bits e não pode ser facilmente adaptado para aceitar um UTF-8- habilitado C

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

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

Você pode, de fato, codificar caracteres UTF-8 em c -strings na fonte. Presumindo que o sistema seja 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 referir-se ao uso de um conjunto expandido (UTF-8) como a localidade C em uma biblioteca C destinada a um ambiente incorporado, de modo que nenhuma outra localidade precise ser carregada para o sistema lidar com UTF-8.

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

Comentários

• O comportamento de várias syscalls é influenciado pelo conjunto de caracteres do local, por exemplo « isupper() não reconhecerá um umlaut A (Ä) como uma letra maiúscula na localidade C padrão. » (de man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint() é outra syscall que também é influenciada pelo fato de que C é definido como somente ASCII.
• Sim, (em teoria) aqueles são influenciados pelos locale, mas esse local geralmente é UTF-8, não é necessariamente ' C ' . No GNU, eles ' estão quebrados a este respeito, no entanto: gnu.org/software/gnulib/manual/html_node/isupper. html Lembre-se de que 100% dos fundamentos de um sistema unix são codificados em C, então a ideia de que " C não ' t lidar com UTF-8 " está bem, simplesmente incorreto e obviamente está. Se um programa escrito em C não pudesse lidar com UTF-8, não ' haveria qualquer UTF-8 no sistema . Período.
• Qv. também a página POSIX isupper () pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " na localidade atual do processo ", não " na localidade C ". Isso também está no padrão ISO, que se refere a " no local C " e " no local atual ", geralmente no formato " se o local atual for o local C " , etc. Lembre-se, novamente, se você estiver no Linux, a implementação do GNU C ' s de algumas das funções ctype está quebrado.
• @gioele Estas são funções de biblioteca, não syscalls. Syscalls são chamadas para o kernel e não são afetadas por locales: locales existem puramente em um nível de usuário.
• @goldilocks ' não é bem verdade que " 100% dos fundamentos de um sistema unix são codificados em C ". Em algum nível, você precisa ter um pouco de assembler, ou possivelmente semelhante a um assembly de C. Os exemplos podem incluir o carregador de boot (sem erro de digitação), o processo real de troca de tarefas e um alguns outros recursos de baixo nível semelhantes. Além disso, eu concordo, C (ou linguagens de nível superior) são provavelmente usados em toda a base de código.