Wat zou er kapot gaan als de C-locale UTF-8 was in plaats van ASCII?

De C-landinstelling is niet de standaardlandinstelling. Het is een locatie die gegarandeerd geen “verrassend” gedrag veroorzaakt. Een aantal opdrachten heeft een gegarandeerde uitvoer (bijv. ps of df headers, date formaat) in de C of POSIX landinstelling. Voor coderingen (LC_CTYPE), is gegarandeerd dat [:alpha:] alleen de ASCII-letters bevat, enzovoort. Als de C landinstelling zou worden gewijzigd, zou dit ertoe leiden dat veel applicaties zich misdragen. Ze kunnen bijvoorbeeld invoer weigeren die ongeldig UTF-8 is in plaats van deze als binaire gegevens te behandelen.

Als u wilt dat alle programmas op uw systeem UTF-8 gebruiken, stelt u de standaardlandinstelling in op UTF-8 . Alle programmas die een enkele codering manipuleren, dat wil zeggen. Sommige programmas manipuleren alleen bytestromen en geven niet om coderingen. Sommige programmas manipuleren meerdere coderingen en geven niet om de landinstelling (bijvoorbeeld een webserver of webclient stelt of leest de codering voor elke verbinding in een header).

Je bent een beetje in de war, denk ik. De “C-locale” is een locale zoals alle andere, die, zoals u opmerkt, conventioneel een synoniem is voor 7-bits ASCII.

Het is ingebouwd in de C-bibliotheek, veronderstel ik dat de bibliotheek heeft een soort van terugval – er kan geen landinstelling zijn.

Dit heeft echter niets te maken met de manier waarop programmas die zijn gebouwd met C-code omgaan met invoer. De landinstelling wordt gebruikt om invoer te vertalen die naar wordt overhandigd, en als de systeemlandinstelling UTF-8 is, is UTF-8 wat het programma krijgt, ongeacht of de bron in C is geschreven of zoiets anders. Dus:

Het zou me verbazen als ik code zou zien die alleen 7-bits schone invoer aankan en niet gemakkelijk kan worden aangepast om een UTF-8- enabled C

Klopt niet echt. Een minimaal stukje standaard C-bron dat van standaardinvoer leest, ontvangt een stroom bytes van het systeem. Als het systeem UTF-8 gebruikt en de stream heeft geproduceerd met behulp van HID-hardware, kan die stream UTF-8-gecodeerde tekens bevatten. Als het ergens anders vandaan komt (bijvoorbeeld een netwerk, een bestand), kan het alles bevatten, wat de aanname van een UTF-8-standaard nuttig maakt.

De feit dat de C-locale een veel beperktere tekenset is dan de UTF-8-locale is niet gerelateerd. Het wordt gewoon “de C-locale” genoemd, maar in feite heeft het niet meer of minder te maken met het samenstellen van C-code dan welke andere dan ook.

U kunt in feite UTF-8-tekens hard coderen in c -strings in de bron. Aangenomen dat het systeem UTF-8 is, zullen die strings er correct uitzien wanneer ze worden gebruikt door het resulterende uitvoerbare bestand.

De “Roger Leigh” -link die u in een opmerking plaatste, verwijst naar mijn mening naar het gebruik van een uitgebreide set (UTF-8) als de C-locale in een C-bibliotheek die bestemd is voor een embedded omgeving, zodat het systeem geen andere locale hoeft te laden om ermee om te gaan UTF-8.

Dus het antwoord op de vraag: “Wat zou breken als de C-locale UTF-8 was in plaats van ASCII?” Is, zou ik raden , niets, maar buiten een ingebedde omgeving, enz. is er niet veel behoefte om dit te doen. Maar zeer waarschijnlijk zal het op een gegeven moment de norm worden voor bibliotheken zoals GNU C (het kan net zo goed zijn, denk ik).

Reacties

• Het gedrag van verschillende syscalls wordt beïnvloed door de tekenset van de landinstelling, bijvoorbeeld « isupper() herkent een A-umlaut (Ä) als een hoofdletter in de standaard C-landinstelling. » (van man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint() is een andere syscall die ook wordt beïnvloed door het feit dat C is gedefinieerd als alleen ASCII.
• Ja, (in theorie) worden die beïnvloed door de locale, maar die locale is meestal UTF-8, het is niet noodzakelijk ' C ' . In GNU zijn ze ' in dit opzicht echter verbroken: gnu.org/software/gnulib/manual/html_node/isupper. html Houd er rekening mee dat 100% van de basisprincipes van een Unix-systeem zijn gecodeerd in C, dus het idee dat " C niet ' t handvat UTF-8 " is goed, gewoon onjuist en duidelijk zo. Als een programma geschreven in C niet kan omgaan met UTF-8, zou er geen ' een UTF-8 op het systeem zijn. Periode.
• Qv. ook de POSIX isupper () pagina pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " in de huidige landinstelling van het proces ", niet " de C-landinstelling ". Dit staat ook in de ISO-norm, die verwijst naar " in de C-landinstelling " en " in de huidige landinstelling ", meestal in de vorm " als de huidige landinstelling is de C-locale " , enz. Houd er nogmaals rekening mee dat als je linux gebruikt, GNU C ' s implementatie van enkele van de ctype-functies is verbroken.
• @gioele Dit zijn bibliotheekfuncties, geen syscalls. Syscalls zijn aanroepen naar de kernel en worden niet beïnvloed door landinstellingen: landinstellingen bestaan puur op gebruikersniveau.
• @goldilocks Het ' is niet helemaal waar dat " 100% van de basisprincipes van een Unix-systeem zijn gecodeerd in C ". Op een bepaald niveau heb je min of meer een beetje assembler nodig, of mogelijk assembly-achtige C. Voorbeelden kunnen zijn: de bootloaderlader (geen typfout), het daadwerkelijke proces van taakwisseling en een enkele andere vergelijkbare low-level features. Bovendien ben ik het ermee eens dat C (of talen op een hoger niveau) waarschijnlijk in de hele codebasis worden gebruikt.