byte\'s -> bits, signed og unsigned.....

int\'en kan du regne dig frem til ret nemt.

værdi1*255^3+værdi2*255^2+værdi3*256+værdi4

den med float skal jeg lige fundere over :)

men den kan også udregnes ved at se hvordan en Java float er opbygget,

Jeg kan gi lidt info om hvordan jeg har forsøgt mig med det indtil nu,
man kan jo via Integer klassen oversætte fra int til bitstrenge, altså sådan ca. sådan her :

int b1 = 14;
int b2 = 0;
int b3 = 0;
int b4 = 0;
       
String byteValue = Integer.toBinaryString(b1) + Integer.toBinaryString(b2) + Integer.toBinaryString(b3) + Integer.toBinaryString(b4);
       
System.out.println(\"ET INT 32 : som bits : \" + byteValue + \" - som int : \" + Integer.valueOf(byteValue,2).intValue());

gir, noget fornuftigt, men hvis jeg f.eks. bruger en negativ værdi som byte, så går det helt galt....

Jeg er lidt på herrens mark, så al hjælp og hints modtages.....

Men hvad så med negative tal...?
Så går den da helt amok, plus at det ikke svare helt til det jeg regnede med :

int b1 = 14;
int b2 = 0;
int b3 = 0;
int b4 = 0;
int resultb = b1*255^3+b2*255^2+b3*255+b4;
System.out.println(\"resultb : \" + resultb);
gir ; resultb : 3571

mens mit andet resultat er 112, som er mere rimeligt....

jeg kan lige nævne at nullet mellem 93 og 14, er nultermineringen af strengen....! derfor skal den bare smides væk...

Brug bit-shifting til at ordne integeren med (jeg kan ikke rigtig forstå hvad det er i laver?):

        byte b1 = 0;
        byte b2 = 0;
        byte b3 = 0;
        byte b4 = 1;

        int converted = (b1<<24) + (b2<<16) + (b3<<8) + b4;
        System.out.println(\"result \" + converted);

delbing : kan du forklare den ?

Det hele handler om at jeg har en UDP pakke, som jeg skal oversætte. Jeg har modtaget pakkens indhold som et byteArray, og jeg ved hvor der f.eks. er en streng og en Int32 osv. i dette byte array, det skal jeg så ha trukket ud af byte arrayet....!

b1<<24 betyder at vi tager bitmønstret for b1 og sætter 24 nuller bagefter. På den måde ender b1 oppe i de 8 højeste bits i en 32bits integer. På den måde klistrer vi de 4 bytes sammen til en integer.

Kan du give mig nogle eksempler jeg kan teste med (dvs nogle byteværdier og deres tilsvarende int32 og float32 værdier)? Jeg tror følgende er ok, men det skal lige testes.
        byte b1 = 0x3f;
        byte b2 = -128;
        byte b3 = 1;
        byte b4 = 1;

        int converted = (b1<<24) | (b2<<16) | (b3<<8) | b4;
        System.out.println(\"resultat som integer: \" + converted);

        int temp;

        boolean negative = (b1 >>> 7)!=0;


        temp = b1 & 0x7f; // fjern første bit
        int temp2 = (b2 >>> 7) & 0x1;
        temp = (temp << 1) | (temp2); // temp holder nu eksponentbitsne
        int exponent = temp-127;
        System.out.println(\"exp: \" + exponent);
        temp = b2 & 0x7f;

        int mantisse = 0x800000 + (temp<<16) + (b3<<8) + b4;
        System.out.println(\"mant: \" + mantisse);
        double d = mantisse * java.lang.Math.pow(2, exponent);
        if (negative) d *= -1;
        System.out.println(\"resultat som float: \" + d);

en float32 er opbygget efter IEEE 754 standarden, dvs:

1. bit er 0 for for positivt tal, 1 for negativt.

2.-9. bit indeholder eksponenten + 127. dvs. at (bitmønstrets unsignede værdi) - 127 = eksponenenten.

10.-32. bit indeholder mantissen, dog uden det forreste 1-tal. dvs tag bitmønstret, sæt et 1 tal foran det, og du har mantissens unsignede bitmønster.

floatens værdi er så mantisse*(2^eksponent), evt. med et minus foran.

jeg har forresten ikke taget højde for de specielle værdier NaN og de 2 Infinities, men den værdi burde vel heller ikke blive sendt?

Smæk en ByteArrayInputStream uden på dit bytearray, dernæst en DataInputStream ud over din ByteArray, så kan du bruge DataInputStreams metoder til læsning, ala:

byte[] bytes = udp.receive();
DataInputStream dis = new DataInputStream(new ByteArrayInputStream(bytes));
String s = dis.readUTF();
long l = dis.readLong();
float f = dis.readFloat();

(Jeg har ikke lige kigget på din encoding af floats, int endians, men det kan du selv kigge på)

nå, men jeg fandt da ud af hvordan IEEE 754 så ud... :)

Tak til logical, det virker som det skal, men din sidste kommentar, er jeg ikke med på.
Jeg har ikke meget hukommelse tilbage om encoding af floats og little og big endian, så har du mod på at se på det også ??????

Kasper

Problemet med rå datatransmission er at der er nogle detaljer, som skal afvejes.

Nogle har angivet en protokol for hvordan de sender ints, strings og float. Afhængig af hvordan de er lagt i en datastrøm kan der være flere problemer. Jeg beskriver et af dem nederst. Hvis du skulle kommunikere med en klient, som ikke er skrevet i java, er der mange måder, hvorpå du lægge strenge ints floats etc. Alene spørgsmålet om en int er 2, 4 eller 8 bytes lang (signed/unsigned), om strenge er null-termineret etc. er faktisk et problem, som man nogle gange skal tage alvorligt.

Hvis det virker for dig, anvender du samme string encoding som din server, samme int definition, og samme float definition. Da jeg ikke lige kender din protokol kunne jeg jo ikke gøre mig nogen forudantagelser om dette.


Et eksempel (endians):

Når man har en 32 bit int, skal den flyttes ud som 4 bytes, men i hvilken rækkefølge? Nogle platforme sender den mest betydende bit (MSB) først, mens andre sender den mindst betydende først (LSB). Dette er henholdsvis big-endian og litte-endian problemet (opkaldt efter Gullivers rejse, hvor nogle mennesker lå i krig om man spiste æg fra den spidste side eller den flade side. Kan ikke huske hvilken side af ægget, der er henholdsvis little og big endian, men hva :-)

Hej igen.

Nu køre hele lortet, dog lige med undtagelse af en lille lidt vigtig ting......

DEN LEDE FLOAT.....

så logical og andre her er den sidste nød :

jeg har et byte array der f.eks. hedder : {68,-27,43,-122}
Dette bytearray udgøre en float32. Denne float32 skal repræcentere en tid, der kan oversættes til min:sek.
Når man finder denne float giver den float værdien : 1833.3601, hvilket af andre bliver oversat til 00:29, hvilket også er lidt mærkeligt....Men det skulle altså angive et tidspunkt.....

Tak for al hjælpen

Jeg melder pas :-)

Det tættest jeg kom var kl. 10:41

Det særlige er jo, at det er så lavt et tal (i minutter sekunder), så man skulle tro, at det enten var tallet 29 i packed format eller noget, men float->time??

hvordan kom du frem til 10:41, for det er passer nemlig meget bedre end det som de andre kommer frem til, men jeg kan sq ikke få de 10:41 frem...?

Tog det som et heltal, konverterede til en dato og tog timer og minutter derfra (Orv, opdagede en fejl, det var minutter og sekunder, der var interessant. Så giver det 10:04:29 (og 10:04 ikke 10:41)).

Håber alle de nestede paranteser giver mening, her er en stump kode:
        byte[] b = {68,-27,43,-122};
        DataInputStream dis = new DataInputStream(new ByteArrayInputStream(b));
        int i = dis.readInt();
        Date d = new Date((long)i);
        SimpleDateFormat formatter = new SimpleDateFormat(\"hh:mm:ss\");
        System.out.println(formatter.format(d));

UUUUUPPPSSSS, hørte et rygte om at de andre regner med timer:min, passer det så ikke lidt bedre ?
Sidste omgang logical, så får du dine points.

Det jeg lavede var jo et gæt.

Jeg har ingen anelse om, og har aldrig hørt om tid repræsenteret som float.
Hvis andre er kommet frem til et resultat, så prøv at høre dem.

Jeg kan jo heller ikke sige, at hvis jeg har et talpar x,y (10,4) så er y altid udledt som x/2-1. Det kunne ligesågodt være x*0,4.

Jeg kan ihvertfald ikke give dig en formel, ligesålidt som jeg har lyst til at sidde at gætte igennem længere tid.

Yeps yeps det virker. Tak for hjælpen alle sammen.
logical var den som kom  med svaret.