Cosa si interromperebbe se la locale C fosse UTF-8 invece di ASCII?

La lingua C non è limpostazione internazionale predefinita. È una localizzazione che garantisce di non provocare alcun comportamento “sorprendente”. Un certo numero di comandi ha un output di una forma garantita (ad es. ps o df intestazioni, date formato) nella lingua C o POSIX. Per le codifiche (LC_CTYPE), è garantito che [:alpha:] contenga solo lettere ASCII e così via. Se la lingua C fosse modificata, molte applicazioni si sarebbero comportate male. Ad esempio, potrebbero rifiutare un input non valido UTF-8 invece di trattarlo come dati binari.

Se desideri che tutti i programmi sul tuo sistema utilizzino UTF-8, imposta la locale predefinita su UTF-8 . Tutti i programmi che manipolano una singola codifica, cioè. Alcuni programmi manipolano solo i flussi di byte e non si preoccupano delle codifiche. Alcuni programmi manipolano più codifiche e non si preoccupano delle impostazioni locali (ad esempio, un server web o un client web imposta o legge la codifica per ciascuna connessione in unintestazione).

Sei un po confuso, credo. “C locale” è una locale come le altre, che, come fai notare, è convenzionalmente un sinonimo di ASCII a 7 bit.

È incorporata nella libreria C, suppongo in modo che il la libreria ha una sorta di fallback – non può esserci alcuna localizzazione.

Tuttavia, questo non ha nulla a che fare con il modo in cui i programmi costruiti dal codice C gestiscono linput. La locale è usata per tradurre linput che viene consegnato a un eseguibile, che se la locale del sistema è UTF-8, UTF-8 è ciò che il programma ottiene indipendentemente dal fatto che la sua sorgente sia stata scritta in C o qualcosa del genere altro. Quindi:

Sarei sorpreso di vedere codice che può gestire solo input pulito a 7 bit e non può essere facilmente adattato per accettare un UTF-8- abilitato C

Non ha davvero senso. Una parte minima della sorgente C standard che legge dallo standard input riceve un flusso di byte dal sistema. Se il sistema utilizza UTF-8 e ha prodotto il flusso da qualche hardware HID, allora quel flusso può contenere caratteri codificati UTF-8. Se proviene da qualche altra parte (ad esempio una rete, un file) potrebbe contenere qualsiasi cosa, il che è ciò che rende utile l presupposto di uno standard UTF-8.

il fatto che la locale C sia un set di caratteri molto più limitato rispetto alla locale UTF-8 non è correlato. Si chiama semplicemente “la locale C”, ma in realtà non ha più o meno a che fare con la composizione del codice C di qualsiasi altro.

Puoi, infatti, codificare i caratteri UTF-8 in c -strings nel sorgente. Presumendo che il sistema sia UTF-8, quelle stringhe appariranno corrette quando usate dalleseguibile risultante.

Il link “Roger Leigh” che hai postato in un commento credo si riferisca alluso di un set espanso (UTF-8) come la locale C in una libreria C destinata a un ambiente embedded, in modo che nessunaltra localizzazione debba essere caricata per il sistema da gestire UTF-8.

Quindi la risposta alla domanda “Cosa si interromperebbe se la locale C fosse UTF-8 invece di ASCII?” È, indovino , niente, ma al di fuori di un ambiente embedded, ecc. non è molto necessario farlo. Ma molto probabilmente diventerà la norma ad un certo punto per librerie come GNU C (potrebbe anche esserlo, credo).

Commenti

• Il comportamento di varie chiamate di sistema è influenzato dal set di caratteri della lingua, ad esempio « isupper() non riconoscerà un A-umlaut (Ä) come lettera maiuscola nella lingua C predefinita. » (da man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint() è un altro syscall che è influenzato anche dal fatto che C è definito solo ASCII.
• Sì, (in teoria) quelli sono influenzati dal locale, ma di solito è UTF-8, non è necessariamente ' C ' . In GNU, tuttavia, ' non funzionano: gnu.org/software/gnulib/manual/html_node/isupper. html Tieni presente che il 100% dei fondamenti di un sistema unix è codificato in C, quindi lidea che " C non ' t handle UTF-8 " va bene, semplicemente sbagliato e ovviamente lo è. Se un programma scritto in C non potesse gestire UTF-8, non ci sarebbe ' UTF-8 sul sistema . Periodo.
• Qv. anche la pagina POSIX isupper () pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " nella lingua corrente del processo ", non " nella lingua C ". Questo è anche nello standard ISO, che fa riferimento a " nella lingua C " e " nella lingua corrente ", generalmente nella forma " se la lingua corrente è la versione locale C " , ecc. Tieni presente, di nuovo, se sei su Linux, limplementazione di GNU C ' di alcune delle funzioni ctype non funziona.
• @gioele Queste sono funzioni di libreria, non chiamate di sistema. Le chiamate di sistema sono chiamate al kernel e non sono influenzate dalle impostazioni locali: le impostazioni locali esistono puramente a livello utente.
• @goldilocks ' non è del tutto vero che " Il 100% dei fondamenti di un sistema unix è codificato in C ". A un certo livello, devi praticamente avere un po di assemblatore, o possibilmente tipo C. Gli esempi potrebbero includere il caricatore del boot loader (nessun errore di battitura), il processo effettivo di cambio di attività e un poche altre caratteristiche di basso livello allo stesso modo. Oltre a ciò, tuttavia, sono daccordo che il C (o linguaggi di livello superiore) è probabilmente utilizzato in tutta la base di codice.