Národní prostředí C je definováno pro použití znakové sady ASCII a POSIX neposkytuje způsob, jak použít znakovou sadu bez změny národního prostředí.
Co by se stalo, kdyby se místo toho přeplo kódování C na UTF-8?
Pozitivní stránkou by bylo, že by se UTF-8 stal výchozí znakovou sadou pro jakýkoli proces, dokonce i pro démony systému. Je zřejmé, že by existovaly aplikace, které by se rozbily, protože předpokládají, že C používá 7bitový ASCII. Ale tyto aplikace skutečně existují? Právě teď je spousta psaného kódu do určité míry vědoma národního prostředí a charsetu, byl bych překvapen, kdybych viděl kód, který pouze zvládne 7bitový čistý vstup a nelze jej snadno přizpůsobit tak, aby přijímal a povoleno UTF-8 C.
Komentáře
odpověď
národní prostředí C není výchozí národní prostředí. Je to národní prostředí, u kterého je zaručeno, že nezpůsobí žádné „překvapivé“ chování. Řada příkazů má výstup v zaručené podobě (např. ps
nebo df
záhlaví, date
formát) v národním prostředí C
nebo POSIX
. U kódování (LC_CTYPE
) je zaručeno, že [:alpha:]
obsahuje pouze písmena ASCII atd. Pokud by bylo změněno národní prostředí C
, znamenalo by to špatné chování mnoha aplikací. Mohou například odmítnout vstup, který je neplatný UTF-8, místo aby s ním zacházeli jako s binárními daty.
Pokud chcete, aby všechny programy ve vašem systému používaly UTF-8, nastavte výchozí národní prostředí na UTF-8 . Všechny programy, které manipulují s jediným kódováním, to je. Některé programy manipulují pouze s bajtovými streamy a nestarají se o kódování. Některé programy se starají o více kódování a nestarají se o národní prostředí (například webový server nebo webový klient nastavuje nebo čte kódování pro každé připojení v záhlaví).
Odpověď
Myslím, že jste trochu zmatení. „C locale“ je národní prostředí jako každé jiné, které, jak podotknete, je běžně synonymem pro 7bitové ASCII.
Předpokládám, že je zabudováno do knihovny C. knihovna má nějaký druh záložní – nemůže existovat žádné národní prostředí.
To však nemá nic společného s tím, jak se programy vytvořené z kódu C zabývají vstupem. Národní prostředí se používá k překladu vstupu, který je předán k spustitelnému souboru, který, pokud je národní prostředí systému UTF-8, je UTF-8 tím, co program získá bez ohledu na to, zda byl jeho zdroj napsán v jazyce C nebo tak něco jiný. Takže:
Byl bych překvapen, kdybych viděl kód, který si poradí pouze se 7bitovým čistým vstupem a nelze jej snadno přizpůsobit pro přijetí UTF-8- enabled C
Ve skutečnosti to nedává smysl. Minimální část standardního zdroje C, který čte ze standardního vstupu, přijímá ze systému proud bajtů. Pokud systém používá UTF-8 a produkoval stream z nějakého HID hardwaru, pak tento stream může obsahovat znaky kódované UTF-8. Pokud pochází odjinud (např. Ze sítě, souboru), může obsahovat cokoli, díky čemuž je předpoklad standardu UTF-8 užitečný.
skutečnost, že národní prostředí C je mnohem omezenější znaková sada než národní prostředí UTF-8, nesouvisí. Jmenuje se to „národní prostředí C“, ale ve skutečnosti to nemá nic společného se skládáním kódu C než kterékoli jiné.
Ve skutečnosti můžete znaky v kódu UTF-8 napevno zakódovat do -strings ve zdroji. Za předpokladu, že systém je UTF-8, budou tyto řetězce vypadat správně, pokud budou použity výsledným spustitelným souborem.
Odkaz „Roger Leigh“, který jste zveřejnili v komentáři, který podle mého názoru odkazuje na použití rozšířená sada (UTF-8) jako národní prostředí C v knihovně C určené pro vložené prostředí, takže pro řešení systému není nutné načítat žádné jiné národní prostředí UTF-8.
Takže odpověď na otázku „Co by se zlomilo, kdyby národní prostředí C bylo místo ASCII UTF-8?“ Je, hádám , nic, ale mimo vestavěné prostředí atd. není třeba to dělat. Je ale velmi pravděpodobné, že se v určitém okamžiku stane normou pro knihovny, jako je GNU C (myslím, že by to tak mohlo být).
Komentáře
- Chování různých systémových volání je ovlivněno znakovou sadou národního prostředí, například «
isupper()
nerozpozná přehlásku A (Ä) jako velké písmeno ve výchozím národním prostředí C. » (z man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint()
je další syscall, který je ovlivněn také skutečností, že C je definováno pouze jako ASCII. - Ano, (teoreticky) jsou ovlivněny národní prostředí, ale toto národní prostředí je obvykle UTF-8, není to nutně ' C ' . V GNU se však ' v tomto ohledu porušili: gnu.org/software/gnulib/manual/html_node/isupper. html Pamatujte, že 100% základů unixového systému je kódováno v jazyce C, takže myšlenka, že " C není ' t handle UTF-8 " je v pořádku, prostě nesprávný a zjevně ano. Pokud by program napsaný v C nemohl pracovat s UTF-8, nebyl by ' v systému žádný UTF-8 . Období.
- Kvv. také stránka POSIX isupper () pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " v aktuálním národním prostředí procesu ", nikoli " v národním prostředí C ". Toto je také v normě ISO, která odkazuje na " v národním prostředí C " a " v aktuálním národním prostředí ", obvykle ve tvaru ", pokud je aktuální národní prostředí národní prostředí C " atd. Nezapomeňte, že pokud používáte linux, implementace GNU C ' některých funkcí ctype je přerušeno.
- @gioele Jedná se o funkce knihovny, nikoli o syscall. Syscalls jsou volání do jádra a nejsou ovlivněna národními prostředími: národní prostředí existují čistě na úrovni uživatele.
- @goldilocks Není to tak úplně pravda ' = „d0a984eeb2″>
100% základů unixového systému je kódováno v C ". Na určité úrovni musíte mít trochu assembleru, nebo možná sestavení jako C. Příklady mohou zahrnovat zavaděč zavaděče (bez překlepu), skutečný proces přepínání úloh a několik dalších podobně nízkoúrovňových funkcí. Kromě toho však souhlasím, že C (nebo jazyky vyšší úrovně) se pravděpodobně používají v celé kódové základně.
C.UTF-8
národní prostředí, stejně jakoPOSIX.UTF-8
.