Limbajul C este definit pentru a utiliza setul de caractere ASCII și POSIX nu oferă o modalitate de a utiliza un set de caractere fără a schimba și setările locale.
Ce s-ar întâmpla dacă codificarea C ar fi schimbată la UTF-8?
Partea pozitivă ar fi că UTF-8 ar deveni setul de caractere implicit pentru orice proces, chiar și demonii de sistem. Evident, ar exista aplicații care s-ar rupe deoarece presupun că C folosește ASCII pe 7 biți. Dar există cu adevărat aceste aplicații? În acest moment, o mulțime de cod scris este conștient de caracteristicile locale și de caractere într-o anumită măsură, aș fi surprins să văd cod care poate doar să se ocupe de intrarea curată pe 7 biți și nu poate fi adaptat cu ușurință pentru a accepta un C. activat pentru UTF-8.
Comentarii
Răspuns
Locația C nu este setarea implicită. Este o locație care este garantată să nu provoace niciun comportament „surprinzător”. Un număr de comenzi au ieșire dintr-un formular garantat (de exemplu, ps sau df anteturi, date format) în C sau POSIX localizare. Pentru codificări (LC_CTYPE), este garantat că [:alpha:] conține doar literele ASCII și așa mai departe. Dacă C a fost modificat, acest lucru ar solicita multe aplicații să se comporte greșit. De exemplu, ar putea respinge intrarea nevalidă UTF-8 în loc să o trateze ca date binare.
Dacă doriți ca toate programele din sistemul dvs. să utilizeze UTF-8, setați setările locale implicite la UTF-8 . Toate programele care manipulează o singură codificare, adică. Unele programe manipulează numai fluxuri de octeți și nu le pasă de codificări. Unele programe manipulează mai multe codificări și nu le pasă de localizare (de exemplu, un server web sau un client web setează sau citește codificarea pentru fiecare conexiune dintr-un antet).
Răspuns
Ești un pic confuz, cred. „Locația C” este o locație ca oricare alta, care, după cum subliniați, este în mod convențional un sinonim pentru ASCII pe 7 biți.
Este încorporat în biblioteca C, presupun, astfel încât biblioteca are un fel de rezervă – nu poate exista nicio localizare.
Cu toate acestea, acest lucru nu are nicio legătură cu modul în care programele construite din codul C se ocupă de intrare. Locația este utilizată pentru a traduce intrarea care este predată către un executabil, care, dacă localizarea sistemului este UTF-8, UTF-8 este ceea ce obține programul indiferent dacă sursa sa a fost scrisă în C sau ceva altceva. Așadar:
Aș fi surprins să văd cod care poate trata doar intrarea curată pe 7 biți și nu poate fi adaptat cu ușurință pentru a accepta un UTF-8- activat C
Nu are sens. O bucată minimă de sursă C standard care citește din intrarea standard primește un flux de octeți de la sistem. Dacă sistemul utilizează UTF-8 și a produs fluxul de pe un anumit hardware HID, atunci acel flux poate conține caractere codate UTF-8. Dacă a venit din altă parte (de exemplu, o rețea, un fișier) ar putea conține orice, ceea ce face utilă presupunerea unui standard UTF-8.
faptul că localizarea C este un set de caractere mult mai restrâns decât localizarea UTF-8 nu are legătură. Tocmai se numește „locația C”, dar de fapt nu are mai mult sau mai puțin de-a face cu compunerea codului C decât oricare altul.
Puteți, de fapt, să introduceți caractere UTF-8 în cod -strings în sursă. Presupunând că sistemul este UTF-8, aceste șiruri vor arăta corect atunci când sunt utilizate de executabilul rezultat.
Linkul „Roger Leigh” pe care l-ați postat într-un comentariu cred că se referă la utilizarea unui set extins (UTF-8) ca locația C dintr-o bibliotecă C destinată unui mediu încorporat, astfel încât nu trebuie încărcată nicio altă localizare pentru ca sistemul să se ocupe UTF-8.
Deci, răspunsul la întrebarea „Ce s-ar rupe dacă localizarea C ar fi UTF-8 în loc de ASCII?” Este, aș ghici , nimic, dar în afara unui mediu încorporat, etc. nu este prea mult nevoie să faceți acest lucru. Dar foarte probabil va deveni norma la un moment dat pentru biblioteci precum GNU C (ar putea fi la fel de bine, cred).
Comentarii
- Comportamentul diferitelor syscalls este influențat de setul de caractere al localizării, de exemplu «
isupper()nu va recunoaște o umlaut A (Ä) ca literă majusculă în setările locale C implicite. » (din man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint()este un alt apel care este influențat și de faptul că C este definit doar ca ASCII. - Da, (în teorie) acestea sunt influențate de locale, dar această localizare este de obicei UTF-8, nu este neapărat ' C ' . În GNU, acestea ' sunt rupte în acest sens, cu toate acestea: gnu.org/software/gnulib/manual/html_node/isupper. html Rețineți că 100% din elementele fundamentale ale unui sistem Unix sunt codificate în C, astfel încât ideea că " C nu ' t handle UTF-8 " este bine, pur și simplu incorect și evident așa. Dacă un program scris în C nu ar putea trata UTF-8, nu ar exista ' niciun UTF-8 pe sistem . Perioadă.
- Qv. de asemenea, pagina POSIX isupper () pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " în locale curente ale procesului ", nu " locale C ". Acest lucru este, de asemenea, în standardul ISO, care se referă la " în C locale " și " în localitatea curentă ", de obicei sub forma " dacă localitatea curentă este localizarea C " etc. Rețineți, din nou, dacă sunteți pe linux, implementarea GNU C ' unele dintre funcțiile ctype sunt defecte.
- @gioele Acestea sunt funcții de bibliotecă, nu syscalls. Syscalls sunt apeluri către kernel și nu sunt afectate de localizări: localizările există pur la nivel de utilizator. = „d0a984eeb2″>
100% din elementele fundamentale ale unui sistem unix sunt codificate în C ". La un anumit nivel, trebuie să aveți un pic de asamblare, sau posibil asemănător C. Exemplele pot include încărcătorul de încărcare (fără greșeală), procesul real de comutare a sarcinilor și un puține alte caracteristici similare la nivel scăzut. În plus, sunt de acord, însă, limbile C (sau limbaje de nivel superior) sunt probabil utilizate în întreaga bază de cod.
C.UTF-8, precum șiPOSIX.UTF-8.