tyyppimuunnokset, Stream, String, StringBuffer
Tässäpä sitten hieman asiasta:
1. Mitä tekee String -luokan getBytes() ?
huom: vakiovastaus kysymykseen löytyy jokaisesta Javan oppikirjasta, ja yleensä kaikissa samalla tavalla puutteellinen / väärin.
Sen tiedänkin jo ihan täsmällisesti, mitä tuo getBytes() tekee silloin, kun ko. merkkijonon kaikki merkit kuuluvat US-ASCII -merkkivalikoimaan (koodit 1..127).
Mutta jo se, että merkkijonossa esiintyy Ä ja Ö -kirjaimia, aiheuttaa sen, että tuon getBytes -metodin toimintatapa ei olekaan ihan itsestäänselvää.
vinkki: esim:
String a = "Tämä";
byte[] b = s.getBytes();
nyt tuon b:n length palauttaa 4 !!!
Javan char -tyyppihän on 16 bittiä ja se tallentaa itseasiassa merkin UNICODE -koodin (=16 bittiä), joka USASCII -merkkien osalta on sama kuin ASCII -koodi tallennettuna 7 alimpaan bittiin, jolloin 9 ylintä bittiä ovat kaikki nollia.
Joku tänne palstalle kirjoittanut oli kokeillut, ja tullut siihen tulokseen, että merkkijonovakiot tallentuvat .jar -tiedostoon utf8 -enkoodattuna, jolloin siis USASCII -merkit ottavat yhden tavun ja esim Ä tai Ö 2 tavua / merkki.
Mutta koska em. b:ssä on 4 tavua, ei se voi käyttää utf8 -koodausta, sillä utf8 -koodauksella merkkijonon "Tämä" ottama tila olisi 6 tavua.
Jos taas merkit 0..255 muunnetaan getBytes() -metodilla aina yhdeksi tavuksi (?), niin mitä getBytes() sitten tekee esim. jollekin thaimerkille ta esim. kreikkalaiselle aakkoselle ?
USASCII:n ulkopuolisten merkkien osalta getBytes():n toimintattapa on siis varsin epäselvä.
2. Eräiden ohjelmointioppaidden mukaan varsinkin J2ME:ssä tulisi välttää olioiden tarpeetonta luomista. Käytännön ohjelmoinnnissa tämä on aika vaikeaa, koska esim. String -tyyppi on ns. immutable, eli kun siihen tehdään muutoksia, niin "muutos" on vain illuusio, eli itseasiassa luodaan uusi merkkijono muutettua sisältöä varten ja vanha jää roskienkeruun harmiksi.
StringBuffer ?
Omassa koodissa voisi tietysti käyttää StringBuffer -luokkaa Stringin sijasta aina kun voi. Mutta esim. käyttöliittymäkomponentit kuitenkin tarvitsevat tiedon yleensä String -muodossa, eli kokonaan String -tyyppiä ei oikein voi välttää.
3. Tyyppimuunnokset / Stream...
ilmeisesti Javassa ei voi tedä suoraa tyyppimuunnosta samoin kuin esim. Delphissä:
T4Bytes = Array[0..3] of Byte;
var
a : T4Bytes;
b : Integer;
begin
b := $11223344;
Integer(a) := b;
end;
Javassa siis vaihtoehdoksi jää (ainakin):
byte[] a = new byte[4];
int b;
b = 0x11223344;
a[0] = b & 0xFF;
a[1] = (b >>> 8)& 0xFF;
a[2] = (b >>> 16)& 0xFF;
a[3] = (b >>> 24)& 0xFF;
Mutta onko tämä todella ainoa vaihtoehto javassakaan ?
mitä, jos kirjoitat Streamiin muuttujan b (tyyppiä int) ?
Jos nyt siirretään Streamin osoitin 4 tavua taaksepäin, eikö nyt voitaisi lukea Streamista muuttuja a ?
Onko javan Stream -luokkien lähdekoodi jossain luettavissa, olisipa kiva nähdä, miten asia on Stream -luokkien toteutuksessa hoidettu!
Eikös Stream -luokkiin voi kirjoittaa (tai niistä lukea) lähes mitä tyyppiä tahansa ?
Onko noissa käytetty jotain "oikotietä" vai perustuuko koko homma siihen, että Stream -luokkaan voi kirjoittaa vain yhden muuttujan kerrallaan, ja ko. muuttuja on aina jotain yksikäsitteisesti määriteltyä tyyppiä, joten Stream -luokan toteutuksessa on täytynyt käsitellä kukin alkeistyyppi erikseen, vai ?
Kommentteja ?
Tässäpä sitten hieman asiasta:
1. Mitä tekee String -luokan getBytes() ?
huom: vakiovastaus kysymykseen löytyy jokaisesta Javan oppikirjasta, ja yleensä kaikissa samalla tavalla puutteellinen / väärin.
Sen tiedänkin jo ihan täsmällisesti, mitä tuo getBytes() tekee silloin, kun ko. merkkijonon kaikki merkit kuuluvat US-ASCII -merkkivalikoimaan (koodit 1..127).
Mutta jo se, että merkkijonossa esiintyy Ä ja Ö -kirjaimia, aiheuttaa sen, että tuon getBytes -metodin toimintatapa ei olekaan ihan itsestäänselvää.
vinkki: esim:
String a = "Tämä";
byte[] b = s.getBytes();
nyt tuon b:n length palauttaa 4 !!!
Javan char -tyyppihän on 16 bittiä ja se tallentaa itseasiassa merkin UNICODE -koodin (=16 bittiä), joka USASCII -merkkien osalta on sama kuin ASCII -koodi tallennettuna 7 alimpaan bittiin, jolloin 9 ylintä bittiä ovat kaikki nollia.
Joku tänne palstalle kirjoittanut oli kokeillut, ja tullut siihen tulokseen, että merkkijonovakiot tallentuvat .jar -tiedostoon utf8 -enkoodattuna, jolloin siis USASCII -merkit ottavat yhden tavun ja esim Ä tai Ö 2 tavua / merkki.
Mutta koska em. b:ssä on 4 tavua, ei se voi käyttää utf8 -koodausta, sillä utf8 -koodauksella merkkijonon "Tämä" ottama tila olisi 6 tavua.
Jos taas merkit 0..255 muunnetaan getBytes() -metodilla aina yhdeksi tavuksi (?), niin mitä getBytes() sitten tekee esim. jollekin thaimerkille ta esim. kreikkalaiselle aakkoselle ?
USASCII:n ulkopuolisten merkkien osalta getBytes():n toimintattapa on siis varsin epäselvä.
2. Eräiden ohjelmointioppaidden mukaan varsinkin J2ME:ssä tulisi välttää olioiden tarpeetonta luomista. Käytännön ohjelmoinnnissa tämä on aika vaikeaa, koska esim. String -tyyppi on ns. immutable, eli kun siihen tehdään muutoksia, niin "muutos" on vain illuusio, eli itseasiassa luodaan uusi merkkijono muutettua sisältöä varten ja vanha jää roskienkeruun harmiksi.
StringBuffer ?
Omassa koodissa voisi tietysti käyttää StringBuffer -luokkaa Stringin sijasta aina kun voi. Mutta esim. käyttöliittymäkomponentit kuitenkin tarvitsevat tiedon yleensä String -muodossa, eli kokonaan String -tyyppiä ei oikein voi välttää.
3. Tyyppimuunnokset / Stream...
ilmeisesti Javassa ei voi tedä suoraa tyyppimuunnosta samoin kuin esim. Delphissä:
T4Bytes = Array[0..3] of Byte;
var
a : T4Bytes;
b : Integer;
begin
b := $11223344;
Integer(a) := b;
end;
Javassa siis vaihtoehdoksi jää (ainakin):
byte[] a = new byte[4];
int b;
b = 0x11223344;
a[0] = b & 0xFF;
a[1] = (b >>> 8)& 0xFF;
a[2] = (b >>> 16)& 0xFF;
a[3] = (b >>> 24)& 0xFF;
Mutta onko tämä todella ainoa vaihtoehto javassakaan ?
mitä, jos kirjoitat Streamiin muuttujan b (tyyppiä int) ?
Jos nyt siirretään Streamin osoitin 4 tavua taaksepäin, eikö nyt voitaisi lukea Streamista muuttuja a ?
Onko javan Stream -luokkien lähdekoodi jossain luettavissa, olisipa kiva nähdä, miten asia on Stream -luokkien toteutuksessa hoidettu!
Eikös Stream -luokkiin voi kirjoittaa (tai niistä lukea) lähes mitä tyyppiä tahansa ?
Onko noissa käytetty jotain "oikotietä" vai perustuuko koko homma siihen, että Stream -luokkaan voi kirjoittaa vain yhden muuttujan kerrallaan, ja ko. muuttuja on aina jotain yksikäsitteisesti määriteltyä tyyppiä, joten Stream -luokan toteutuksessa on täytynyt käsitellä kukin alkeistyyppi erikseen, vai ?
Kommentteja ?
Vastaukset 5
Vanhimmat
getBytes() ratkaisusta...
Tutkin hieman itse asiaa...
getBytes() palauttaa ainakin merkkien 1..255 osalta kyseisen merkin unicode -koodin tavuna.
huom:
1. On edelleen epäselvää, mitä tuo getBytes() palauttaa vaikkapa kreikkalaisten, thaimaalaisten tai venäläisten kirjaimien osalta.
2. javassahan tyyppi byte on etumerkillinen eli voi saada arvot -128 .. 127.
Tästä johtuen muunnettaessa takaisin merkiksi muunnos saadaan toimimaan oikein näin:
muuttujaa code EI saa määritellä byte:ksi, vaan esim. int -tyyppiseksi. Sen jälkeen:
if (code < 0) {
code := 256;
}
sb.append((char)code);
sb siis on tyyppiä StringBuffer
pelkkä:
sb.append((char)code);
toimii väärin, eli jos alkuperäisen merkin unicode -koodi on väliltä 128..255, niin silloin tuo code onkin väliltä -128 .. -1, ja sen castaaminen char -tyyppiseksi EI toimi oikein !
mutta jos merkin UNICODE -koodi on arvoalueen 1..255 ulkopuolella, en edelleenkään tiedä, mitä tuo getBytes() tekee.
koodi 0 onkin mielenkiintoinen rajatapaus: C/C -kielessähän sitä käytetään merkkijonon terminoijana, mutta käsittääkseni puhtaassa javakoodissahan sitä ei tuohon tarvita, joten sen kohtelu getBytes() -metodissa on myös epäselvä.
Vähän vaikea sanoa mitä tuo tekee thaimerkeille, kun Sunin oma API -määrittelee sen näin: "The behavior of this method when this string cannot be encoded in the default charset is unspecified."
Suosittelevat sitten tekemään näin: The CharsetEncoder class should be used when more control over the encoding process is required.
1. Jep, Stringin getBytes:iä ei kannata käyttää, ellei varmasti tiedä mitä se sisältää.
2. Olioiden luomista tulisi varmaan välttää, koska mobiilialustoilla on vähemmän muistia käytettävissään. Mutta ne oliot mitkä tarvitset pitää saada luoda. Jos muisti ei riitä, on ohjelmasi liian raskas kyseisellä alustalla.
3. Eli haluat tehdä 32-bittisestä integeristä byte-taulukon? Varmaan tuo sun esimerkkisi on hyvä tapa. Mutta haluatko tehdä tämän streamausta varten, esim. lähettääksesi integer-muuttujan arvon verkon yli? Tällöin kannattaa ennemmin käyttää esim. ObjectOutputStream:ia (ja toisessa päässä tietenkin ObjectInputStreamia), jonka writeInt-metodilla kirjoitat (ja readInt-metodilla luet) integer-tyypit suoraan ilman omia kikkailuja. Streamit sisältävät metodit minkä tahansa primitiivisen tietotyypin, sekä serialisoituvien olioiden lukemiseen ja kirjoittamiseen.
kohdasta 2 piti vielä sanoa, että StringBuffer käyttää Stringejä sisäisesti, joten ei silläkään String-olioiden luomista vältä.
1. Tässä
string.getBytes("UTF-8");
string.getBytes("ISO-8859-1");
ja vastaavasti
new String(bytes,"UTF-8");
2. StringBuffer on käytössä automaattisesti kääntäjä muuttaa stringi kikkailut StringBufferiksi.
Muistetaan ne optimointi säännöt...
3. Java byteBuffer
ByteBuffer a = ByteBuffer.allocate(10);
a.putInt(0x11223344);
a.flip();
a.get() ja a.get(1); jne, sukulaisia löytyy