Hvad ville bryde, hvis C-lokaliteten var UTF-8 i stedet for ASCII?

C-lokalitet er ikke standardsprog. Det er et sted, der garanteret ikke forårsager nogen “overraskende” adfærd. Et antal kommandoer har output af en garanteret form (f.eks. ps eller df headere, date format) i C eller POSIX landestandard. For kodninger (LC_CTYPE) garanteres det, at [:alpha:] kun indeholder ASCII-bogstaverne og så videre. Hvis C locale blev ændret, ville dette kalde mange applikationer til at opføre sig forkert. For eksempel kan de afvise input, der er ugyldig UTF-8 i stedet for at behandle det som binære data.

Hvis du vil have, at alle programmer på dit system skal bruge UTF-8, skal du indstille standardprogrammet til UTF-8. . Alle programmer, der manipulerer en enkelt kodning, dvs. Nogle programmer manipulerer kun byte-streams og er ligeglad med kodninger. Nogle programmer manipulerer flere kodninger og er ligeglad med lokaliteten (for eksempel indstiller eller læser en webserver eller webklient kodningen for hver forbindelse i et header).

Du er lidt forvirret, tror jeg. “C-lokaliteten” er en lokalitet som enhver anden, som, som du påpeger, traditionelt er et synonym for 7-bit ASCII.

Det er indbygget i C-biblioteket, formoder jeg, at biblioteket har en slags tilbageslag – der kan ikke være noget sted.

Dette har dog ikke noget at gøre med, hvordan programmer bygget fra C-kode håndterer input. Lokaliteten bruges til at oversætte input, der er afleveret til en eksekverbar, som hvis systemets lokalitet er UTF-8, UTF-8 er, hvad programmet får, uanset om dets kilde blev skrevet i C eller noget andet. Så:

Jeg ville blive overrasket over at se kode, der kun kan håndtere 7-bit ren input og ikke let kan tilpasses til at acceptere en UTF-8- aktiveret C

Det giver ikke rigtig mening. Et minimalt stykke standard C-kilde, der læser fra standardinput, modtager en strøm af bytes fra systemet. Hvis systemet bruger UTF-8, og det producerede strømmen fra noget HID-hardware, kan den strøm muligvis indeholde UTF-8-kodede tegn. Hvis det kom fra et andet sted (f.eks. Et netværk, en fil), kan det indeholde noget, hvilket er det, der gør antagelsen for en UTF-8-standard nyttig.

det faktum, at C-lokaliteten er et meget mere begrænset tegnsæt, end UTF-8-lokalet, er ikke relateret. Det kaldes bare “C-lokalitet”, men faktisk har det ikke mere eller mindre at gøre med at komponere C-kode end nogen anden.

Du kan faktisk UTF-8 tegn i hardcode i c -strenge i kilden. Hvis vi antager, at systemet er UTF-8, vil disse strenge se korrekte ud, når de bruges af den resulterende eksekverbare. udvidet sæt (UTF-8) som C-lokaliteten i et C-bibliotek bestemt til et indlejret miljø, så der ikke skal indlæses nogen anden lokalitet til systemet at håndtere UTF-8.

Så svaret på spørgsmålet, “Hvad ville bryde, hvis C-lokaliteten var UTF-8 i stedet for ASCII?” Er, jeg ville gætte intet, men uden for et indlejret miljø osv. er der ikke meget behov for at gøre dette. Men meget sandsynligt vil det blive normen på et eller andet tidspunkt for biblioteker som GNU C (det kan lige så godt være, tror jeg).

Kommentarer

• Opførelsen af forskellige syscalls er påvirket ved lokalets tegnsæt, for eksempel « isupper() genkender ikke en A-umlaut (Ä) som et stort bogstav i standard C-lokalitet. » (fra man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint() er en anden syscall, der også påvirkes af det faktum, at C er defineret som kun ASCII.
• Ja, (i teorien) er de påvirket af landestandard, men lokaliteten er normalt UTF-8, det er ikke nødvendigvis ' C ' . I GNU er de ' dog brudt i denne henseende: gnu.org/software/gnulib/manual/html_node/isupper. html Husk, at 100% af fundamentet for et unix-system er kodet i C, så ideen om, at " C ikke ' t håndtag UTF-8 " er godt, bare forkert og tydeligvis også. Hvis et program skrevet i C ikke kunne håndtere UTF-8, ville der ikke være ' nogen UTF-8 på systemet . Periode.
• Qv. også POSIX isupper () side pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " i den aktuelle lokalitet for processen ", ikke " C-lokaliteten ". Dette er også i ISO-standarden, der refererer til " i C-lokaliteten " og " i den aktuelle lokalitet ", normalt i form " hvis den aktuelle lokalitet er C-lokaliteten " osv. Husk igen, hvis du er på linux, skal GNU C ' implementering af nogle af ctype-funktionerne er brudt.
• @gioele Dette er biblioteksfunktioner, ikke syscalls. Skysamtal er opkald til kernen og påvirkes ikke af lokaliteter: lokaliteter findes rent brugerniveau.
• @goldilocks Det ' er ikke helt rigtigt, at " 100% af fundamentet for et unix-system er kodet i C ". På et eller andet niveau skal du stort set have lidt montør eller muligvis montagelignende C. Eksempler kan omfatte boot loader (ingen typefejl), den faktiske proces med opgaveændring og en få andre lignende funktioner på lavt niveau. Ud over det er jeg dog enig i, at C (eller sprog på højere niveau) sandsynligvis bruges i hele kodebasen.