Mikä rikkoisi, jos C-kieli olisi UTF-8 ASCII: n sijasta?

C-kielialue on määritetty käyttämään ASCII-merkistöä, eikä POSIX tarjoa tapaa käyttää merkistöä muuttamatta myös aluetta.

Mitä tapahtuisi, jos C: n koodaus vaihdettaisiin UTF-8: een?

Positiivinen puoli olisi, että UTF-8: sta tulisi oletusmerkkijärjestelmä mille tahansa prosessille, jopa järjestelmädemonille. On tietysti olemassa sovelluksia, jotka hajoavat, koska ne olettavat, että C käyttää 7-bittistä ASCII: ta. Mutta onko näitä sovelluksia todella olemassa? Tällä hetkellä suuri osa kirjoitetusta koodista on tietyssä määrin kieli- ja merkistötietoinen, olisin yllättynyt nähdessäni koodin, joka vain käsittelee 7-bittistä puhdasta syötettä eikä sitä voida helposti mukauttaa hyväksymään a UTF-8-yhteensopiva C.

Kommentit

  • Tämä ketju vuodelta 2009 keskustelee UTF-8-pohjaisen C-kielen tarpeesta, mutta ei käsittele POSIXin rikkomisen ongelmaa.
  • FWIW, OpenBSD: llä on C.UTF-8 kielialue, samoin kuin POSIX.UTF-8.

Vastaa

C-kieli ei ole oletuskieli. Se on kielialue, joka ei taatusti aiheuta mitään ”yllättävää” käyttäytymistä. Monilla komennoilla on taattu muoto (esim. ps tai df otsikot, date format) C tai POSIX kielialueella. Koodauksille (LC_CTYPE) on taattu, että [:alpha:] sisältää vain ASCII-kirjaimia ja niin edelleen. Jos C -aluetta muokataan, tämä vaatisi monia sovelluksia toimimaan väärin. He saattavat esimerkiksi hylätä virheellisen UTF-8-syötteen sen sijaan, että sitä kohdellaan binääritiedona.

Jos haluat, että kaikki järjestelmän ohjelmat käyttävät UTF-8: ta, aseta oletuskieleksi UTF-8. . Kaikki ohjelmat, jotka manipuloivat yhtä koodausta, toisin sanoen. Jotkut ohjelmat käsittelevät vain tavuvirtoja, eivätkä välitä koodauksista. Jotkut ohjelmat manipuloivat useita koodauksia ja välittävät kieliversiosta (esimerkiksi verkkopalvelin tai web-asiakas asettaa tai lukee kunkin yhteyden koodauksen otsikossa).

Vastaa

Olet hieman hämmentynyt. ”C locale” on kuten kaikki muutkin locale, joka, kuten huomautat, on tavallisesti synonyymi 7-bittiselle ASCII: lle.

Se on rakennettu C-kirjastoon, luulen, että kirjastolla on jonkinlainen varavoima – aluetta ei voi olla.

Tällä ei kuitenkaan ole mitään tekemistä sen kanssa, miten C-koodista rakennetut ohjelmat käsittelevät syötettä. Lokaleita käytetään kääntämään syötettä, joka luovutetaan to suoritettavalle tiedostolle. Jos järjestelmän locale on UTF-8, UTF-8 on se, mitä ohjelma saa riippumatta siitä, onko lähde kirjoitettu C-muodossa vai jotain muuta muu. Joten:

Olisin yllättynyt nähdessäni koodin, joka pystyy käsittelemään vain 7-bittistä puhdasta syötettä eikä sitä voida helposti mukauttaa hyväksymään UTF-8- käytössä C

Ei ole mitään järkeä. Pieni pala tavallista C-lähdettä, joka lukee vakiotulosta, vastaanottaa tavuvirran järjestelmästä. Jos järjestelmä käyttää UTF-8: ta ja se tuotti virran jostakin HID-laitteistosta, kyseinen virta voi sisältää UTF-8-koodattuja merkkejä. Jos se on peräisin muualta (esim. Verkosta, tiedostosta), se voi sisältää mitä tahansa, mikä tekee UTF-8-standardin olettamuksesta hyödyllisen.

tosiasia, että C-kieli on paljon rajoitetumpi char-joukko kuin UTF-8-kielialue, ei liity. Sitä kutsutaan vain ”C-kieleksi”, mutta itse asiassa sillä ei ole enempää tai vähemmän tekemistä C-koodin kirjoittamisen kanssa kuin millään muulla.

Voit itse asiassa koodata UTF-8-merkkejä c-muotoon -merkkijonot lähteessä. Jos järjestelmä on UTF-8, nämä merkkijonot näyttävät oikeilta, kun tuloksena oleva suoritustiedosto käyttää niitä.

Kommentissa lähettämäsi ”Roger Leigh” -linkki viittaa mielestäni laajennettu joukko (UTF-8) kuten C-kirjaston C-kieli, joka on tarkoitettu upotettuun ympäristöön, joten mitään muuta aluetta ei tarvitse ladata, jotta järjestelmä käsittelee UTF-8.

Joten vastaus kysymykseen ”Mikä rikkoisi, jos C-kieli olisi UTF-8 ASCII: n sijaan?” On arvaus , ei mitään, mutta sulautetun ympäristön jne. ulkopuolella ei ole paljon tarvetta tehdä sitä. Mutta hyvin todennäköisesti siitä tulee jossain vaiheessa normi kirjastoille, kuten GNU C: lle (se voi myös olla, luulen).

Kommentit

  • Eri sysallien käyttäytymiseen vaikuttaa esimerkiksi locale-merkkisarjan avulla « isupper() ei tunnista A-umlautia (Ä) isona kirjaimena C-oletusalueella. » (from man7.org/linux/man-pages/ man3 / isprint.3.html ).isprint() on toinen syscall, johon vaikuttaa myös se tosiasia, että C määritellään vain ASCII: ksi.
  • Kyllä, (teoriassa) niihin vaikuttaa mutta se on yleensä UTF-8, se ei välttämättä ole ' C ' . GNU: ssa he ' rikkoutuvat tältä osin: gnu.org/software/gnulib/manual/html_node/isupper. html Muista, että 100% unix-järjestelmän perusteista on koodattu C: hen, joten ajatus siitä, että " C ei ' t -kahva UTF-8 " on hyvin, vain väärä ja ilmeisesti niin. Jos C: ssä kirjoitettu ohjelma ei pysty käsittelemään UTF-8: ta, järjestelmässä ei ole ' mitään UTF-8: ta. Aika.
  • Qv. myös POSIX isupper () -sivu pubs.opengroup.org/onlinepubs/9699919799/functions/isupper.html " prosessin nykyisessä kieliversiossa ", ei " C-kielessä ". Tämä on myös ISO-standardissa, joka viittaa " C-kielessä " ja " nykyisessä kielialueessa ", yleensä muodossa ", jos nykyinen kielialue on C-kieli " jne. Muista vielä kerran, että jos olet linuxissa, GNU C ' -sovelluksen toteutus osa ctype-funktioista on rikki.
  • @gioele Nämä ovat kirjastotoimintoja, eivät syscalls. Syscallit ovat kutsuja ytimeen, eikä lokalisoinnit vaikuta niihin: paikalliset kielet ovat puhtaasti käyttäjätasoisia.
  • @goldilocks Se ' ei ole totta, että " 100% unix-järjestelmän perusteista on koodattu koodiin C ". Jossakin tasolla sinulla on melkein oltava vähän kokoonpanijaa tai mahdollisesti kokoonpanon kaltainen C. Esimerkkejä voivat olla käynnistyslataimen latausohjelma (ei kirjoitusvirhettä), tehtävän vaihtamisen varsinainen prosessi ja muutamia muita vastaavan matalan tason ominaisuuksia. Tämän lisäksi olen kuitenkin samaa mieltä siitä, että C: tä (tai korkeamman tason kieliä) käytetään todennäköisesti koko koodipohjassa.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *