Molemmathan ovat 16 bittiä pitkiä. Miksi siis pitäisi käyttää jompaa kumpaa? Esimerkiksi C-kielessähän char on 8-bittinen, jolloin ei synny päällekkäisyyksiä.
Mitä käytännön eroa charilla ja shortilla?
harjoittelia
173058
0Äänestä
Muut lukivat myös
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 17
Vanhimmat
Eri tietotyypeillä kerrotaan mm. kääntäjälle/tulkille miten paljon sen täytyy varata resursseja (esim muistia) ja ohjelmoijalle millaisia arvoja se tulee saamaan.
16 bitin char on tarkoitettu merkeille ja symboleille. Tosin se on vähän huono (ja rajoitettu) koska siihen ei mahdu kaikki unicode merkit vaan osajoukko siitä (parempi on esim. utf8 jne)
"Tosin se on vähän huono (ja rajoitettu) koska siihen ei mahdu kaikki unicode merkit vaan osajoukko siitä (parempi on esim. utf8 jne)"
Tuon kun olisit jättänyt sanomatta, olisi viestisi mennyt läpi kuin väärä raha, ei jatkoon.
Kiinteään 16-bittiseen muuttujaan mahtuu vain 65 536 eri merkkiä kun esim. 32-bittiseen (UTF-32) mahtuu reilusti yli miljoona ja samoin mahtuu vaihtevan pituiseen UTF-8 merkkiin. UTF-8 vie Suomessa eniten käytetyillä (ASCII ) merkeillä vähemmän muistia.
Ubuntun UTF-8 vie hyvin vähän muistia, ja se on hyvin nopea. Ubuntun (ASCII ) merkeillä osaa kuka vaan kirjoittaa. olen käyttänyt kaikki ubuntun 32-bittiä ainakin kertaalleen. Ubuntu on paras aloittelevalle koska siihen mahtuu 65 536 eri merkkiä. minä tiedän nämä ubuntu jutut kaikista parhaitten olen käyttänyt ubuntua 8 vuotta.
Mä oon vasta saanu 9 bittiä täyteen ubuntussa. Hyvä että jää säästöön niitäkin koska tämä pitkäaikaistyöttömyys vaan jatkuu. Saisinko sossusta lisää bittejä Ulbuntuun?
Esim. Lazarus käyttää oletuksena UTF-8 merkistöä.
Kirjoittamalla Lazaruksessa käsky
joka tulostaa merkkijonon pituuden
length('Ostoskorin hinta on 100,- €').ToString
esim. Memo1.Lines.Add(); sulkeiden sisään jolloin
se tulostuu TMemo komponenttiin eli muistioon.
Nähdään että tämän merkkijonon pituus on 29 tavua.
Muut merkit (jotka ovat perinteisiä ASCII merkkejä) kuin euron merkki
veivät vain yhden tavun mutta euron merkki vie 3 tavua.
Jos tuo merkkijono olisi toteutettu UTF-32 merkistönkoodauksella
se olisi viennyt 108 tavua.
En ole Lazarusta käyttänyt mutta tuli mieleen että miten mahtaa vaikuttaa suorituskykyyn se että merkkijonot ovat sisäisesti talletettuina UTF8:ksi. Jos vaikka on iso läjä merkkijonoja järjestettävänä aakkoskärjestykseen niin nehän pitää ensin purkaa UTF8:sta toiseen muotoon, jota voi käyttää vertailuissa.
Enemmän on merkitystä millaisella lajittelualgoritmillä lajitellaan ja mikä on lajittelun lähtötilanne.
Lueppa seuraava linkki:
http://wiki.freepascal.org/UTF-8/fi
Eli näin yleisesti ottaen UTF-8 merkit eivät ole mitenkään erikoisesti pakattu.
Char on etumerkitön ja short etumerkillinen.
"etumerkillinen" eli alkukirjain ja tarkoitat varmaan Char alkaa isolla C kirjaimella ja short alkaa pienellä s-kirjaimella.
En tarkoittanut.
Tarkotitpas, ala vaan tunnustaa, et vain tuntenut alkukirjain sanaa ja käytit yksikertaisuutesi vuoksi etumerkillinen sanaa, joka on tietysti sinun oma vastineesi alkukirjaimelle.
En tarkoittanut mitään alkukirjaimia. Mikä alkukirjain edes on? Onko se vastaava kuin alkuluku numeropuolella?
Älä nyt ala hankalaksi, alkulukujesi kanssa. Onko tässä (24.3.2019) 24 alkuluku, 3 keskiluku ja 2019 loppuluku. Minä tiedän että keksit alkukirjaimelle omanvastineen (etumerkki), varsin omaperäistä sanojen muunnosta sinulta.
Minä kehitin siis etumerkillisen 32-bittisen rahayksikköluvun, jolla ei tapahdu pyöristysvirheitä. MSB (most signifant bit) määrittää etumerkin, seuraavat 24 bittiä ovat kokonaislukuosuus (esim eurot) ja 7 alinta bittiä kertovat sadasosat (esim. sentit). Tuolla voidaan ilmoittaa rahamäärä –16 777 216,99 – 16 777 216,99. Rittää tavallisen kotitalouden kirjanpitoon ja laskentaan.
Omat tyypit on hieno asia mutta joissakin kielissä on valmiina Currency tyyppi tätä varten.
Kun Currency tyyppi on valmiina niin silloin ei tarvitse tehdä oparaattoria peruslaskutoimitukseen
Tuo vertaus C -kieleen:
C -kieli on kielenä alkeellinen.
Siksi C -kielessä char on sekä merkki (8 -bittinen sellainen) että samalla 8 -bittinen kokonaislukutyyppi.
Javassa, ja myös Delphissä merkkityypit ja kokonaislukutyypit eivät ole suoraan yhteensopivia keskenään (ja hyvä niin).
Jos tarvitsee muuntaa merkkityyppien ja kokonaislukutyyppien välillä, siihen on omat muunnosfunktionsa.
Javassa tosiaan char on 16-bittinen. Taustalla ilmeisesti jokin varhainen UNICODEn versio, jossa UNICODE silloin tarkoitti UCS-2. Nykyisin tuo rajoittunut UNICODEn versio mahdollistaa sellaisenaan ns BMP:n (Basic Multilingual Page) sisältämien merkkien käytön.
Lisäksi: mikä tahansa BMP:n ulkopuolinen merkki on koodattavissa kahdella UCS2Char -tyyppisellä "merkillä" joista toinen on low surrogate ja toinen high surrogate.
JA tuo javan char -tyyppi on siis samalla UCS2Char.
ASCII menee UTF-8:lla 1 tavu = 1 merkki -periaatteella.
Suomenkielinen teksti menee pääosin tuolla 1 tavu = 1 merkki -periaatteella, poikkeuksena å, ä, ö ja jos aiheena on Saksan kaupungit niin esim ü esiintyy sanassa München. Englanninkielisissä maissa tuosta Saksan kaupungista käytetään nimeä Munich, ehkä siksi kun ü on liian vaikea kirjain jenkkien opeteltavaksi (kuten ovat myös å, ä ja ö).
å,ä,ö,ü ja Å, Ä, Ö, Ü vaativat UTF-8 -koodattuna 2 teknistä merkkiä eli 2 tavua.
UTF-16 ja UCS-2 -koodauksessa ne vaativat 1 teknistä merkkiä eli 2 tavua.
Noita BMP:n ulkopuolisia merkkejä ei kovin usein tarvita.
Yksi esimerkki, missä niitä tarvitaan:
Raamatun alkukielet ovat kreikka, heprea ja aramea.
tuo aramea on sellainen kieli, että sen kirjoitusmerkit eivät kuulu tuohon BMP eli niitä ei voi esittää UCS-2 koodauksella lainkaan ja UTF-16:ssa jokainen arameankielinen merkki = surrogate -pari = 2 teknistä merkkiä eli 4 tavua.
Eli siis :
UTF-8:ssa: 1 tekninen merkki = 1 tavu.
UTF-16:ssa: 1 tekninen merkki = 2 tavua.
UTF-32:ssa: 1 tekninen merkki = 4 tavua.
englanniksi tuo tekninen merkki = encoding unit.
Kaikissa koodauksissa (UTF-8, UTF-16 ja UTF-32) maksimi tilantarve yhdelle oikealle merkille on 4 tavua.
tuossa "oikea merkki" = UNICODE -kooditaulusta löytyvä merkki.
Juu, on olemassa ns. komposiittimerkkejä, mutta ainakin suurimmalle osalle (kaikille?) löytyy ns. precomposed -vaihtoehto, ja jos löytyy, tulee ko. precomposed -vaihtoehtoa myös käyttää !
Käytetään siis precomposed -vaihtoehtoa Ä, EIKÄ käytetä "2 pistettä yhdistettynä seuraavaan merkkiin" A -vaihtoehtoa !
Osa merkeistä on jopa tietoturvamielessä haitallisia.
Jos jokin merkki on sellainen, että se määrää siirtymään 1 pykälä vasemmalle, niin sitä väärinkäyttämällähän voi luoda vaikkapa URLin, joka näyttää samalta kuin toinen URL.
Erilaisiin kusetuksiin mainio kikka.
Tuollaisia merkkejä väärinkäyttämällä voisi vaikkapa luoda linkin, joka näyttäisi vievän tunnettuun verkkopankkiin, mutta viekin sen väärennettyyn versioon, joka on rikollisten hallinnassa.
Joissain kielissä (arabi ?) normaali kirjoitussuunta on oikealta vasemmalle. Mutta kun tuo piirre on sisällytetty UNICODE -järjestelmään, tuliko samalla vahingossa luotua mahdollisuuksia verkkorikollisille kun voi luoda vale -URLeja, jotka näyttävät oikealta, mutta eivät ole sitä ?