Quest-ce qui casserait si la locale C était UTF-8 au lieu dASCII?

Les paramètres régionaux C nest pas le paramètre régional par défaut. Cest une locale qui est garantie de ne provoquer aucun comportement «surprenant». Un certain nombre de commandes ont une sortie de forme garantie (par exemple, ps ou df en-têtes, date format) dans les paramètres régionaux C ou POSIX. Pour les encodages (LC_CTYPE), il est garanti que [:alpha:] ne contient que les lettres ASCII, et ainsi de suite. Si la locale C était modifiée, cela entraînerait un mauvais comportement de nombreuses applications. Par exemple, ils peuvent rejeter une entrée non valide UTF-8 au lieu de la traiter comme des données binaires.

Si vous voulez que tous les programmes de votre système utilisent UTF-8, définissez les paramètres régionaux par défaut sur UTF-8 . Tous les programmes qui manipulent un seul encodage, cest-à-dire. Certains programmes ne manipulent que les flux doctets et ne se soucient pas des encodages. Certains programmes manipulent plusieurs encodages et ne se soucient pas des paramètres régionaux (par exemple, un serveur Web ou un client Web définit ou lit lencodage de chaque connexion dans un en-tête).

Vous êtes un peu confus, je pense. La « locale C » est une locale comme une autre, qui, comme vous le faites remarquer, est conventionnellement synonyme de 7 bits ASCII.

Elle est intégrée à la bibliothèque C, je suppose que le la bibliothèque a une sorte de solution de secours – il ne peut pas y avoir de locale.

Cependant, cela na rien à voir avec la façon dont les programmes construits à partir du code C traitent les entrées. La locale est utilisée pour traduire lentrée qui est transmise à un exécutable, qui si la locale du système est UTF-8, UTF-8 est ce que le programme obtient indépendamment du fait que sa source ait été écrite en C ou quelque chose. autre. Donc:

Je serais surpris de voir du code qui ne peut traiter que des entrées propres 7 bits et qui ne peut pas être facilement adapté pour accepter un UTF-8- enabled C

Cela na pas vraiment de sens. Un élément minimal de source C standard qui lit à partir dune entrée standard reçoit un flux doctets du système. Si le système utilise UTF-8 et quil a produit le flux à partir dun matériel HID, alors ce flux peut contenir des caractères codés UTF-8. Sil vient dun autre endroit (par exemple, un réseau, un fichier), il peut contenir nimporte quoi, ce qui rend utile lhypothèse dun standard UTF-8.

Le le fait que la locale C est un jeu de caractères beaucoup plus restreint que la locale UTF-8 nest pas lié. On lappelle simplement « la locale C », mais en fait cela na ni plus ni moins à voir avec la composition de code C que tout autre.

Vous pouvez, en fait, coder en dur les caractères UTF-8 en c -strings dans la source. En supposant que le système est UTF-8, ces chaînes sembleront correctes lorsquelles seront utilisées par lexécutable résultant.

Le lien « Roger Leigh » que vous avez publié dans un commentaire fait référence à lutilisation dun ensemble étendu (UTF-8) comme la locale C dans une bibliothèque C destinée à un environnement embarqué, de sorte quaucune autre locale ne doive être chargée pour que le système soccupe UTF-8.

Donc, la réponse à la question « Quest-ce qui casserait si la locale C était UTF-8 au lieu dASCII? » Est, je devine , rien, mais en dehors dun environnement embarqué, etc., il nest pas vraiment nécessaire de le faire. Mais très probablement, cela deviendra la norme à un moment donné pour des bibliothèques telles que GNU C (cela pourrait aussi bien lêtre, je pense).

Commentaires

• Le comportement des différents appels système est influencé par le jeu de caractères des paramètres régionaux, par exemple « isupper() ne reconnaîtra pas un A-umlaut (Ä) comme une lettre majuscule dans les paramètres régionaux par défaut C. » (from man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint() est un autre appel système qui est également influencé par le fait que C est défini comme ASCII uniquement.
• Oui, (en théorie) ceux-ci sont influencés par le locale, mais cette locale est généralement UTF-8, ce nest pas nécessairement ' C ' . Dans GNU, ils ' sont cassés à cet égard, cependant: gnu.org/software/gnulib/manual/html_node/isupper. html Gardez à lesprit que 100% des principes fondamentaux dun système unix sont codés en C, donc lidée que " C ne ' t handle UTF-8 " est bien, tout simplement incorrect et évidemment. Si un programme écrit en C ne pouvait pas traiter UTF-8, il ny aurait ' aucun UTF-8 sur le système . Période.
• Qv. également la page POSIX isupper () pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " dans la locale actuelle du processus ", et non " la locale C ". Ceci est également dans la norme ISO, qui fait référence à " dans les paramètres régionaux C " et " dans la langue actuelle ", généralement sous la forme " si la langue actuelle est la locale C " , etc. Gardez à lesprit, encore une fois, si vous êtes sous Linux, limplémentation de GNU C ' de certaines fonctions ctype est cassée.
• @gioele Ce sont des fonctions de bibliothèque, pas des appels système. Les appels système sont des appels au noyau et ne sont pas affectés par les locales: les locales existent uniquement au niveau de lutilisateur.
• @goldilocks Il ' nest pas tout à fait vrai que " 100% des fondamentaux dun système unix sont codés en C ". À un certain niveau, vous devez pratiquement avoir un peu dassembleur, ou peut-être un assembleur C. Des exemples peuvent inclure le chargeur de démarrage (pas de faute de frappe), le processus réel de changement de tâche et un quelques autres fonctionnalités de bas niveau similaires. En plus de cela, cependant, je suis daccord, le C (ou les langages de niveau supérieur) sont probablement utilisés dans toute la base de code.