Data conversion When Java communicates with C + + networks

Recently made an Android app that requires data to be passed through the socket with the PC side. PC-side is developed in C + +, in order to facilitate transmission, before sending the data into a byte array. I thought I could do everything, but there are still some problems in the process. Here are some of the problems I have encountered and solutions, here to do a simple record, but also hope that we can quickly solve the problem, but also welcome you to add

Receiving and sending of Java sockets

First we will create a socket connection and then get InputStream and outputstream from it. When I received it, I used a datainputstream to wrap the inputstream of the socket so that the data types of different sizes could be received later. The OutputStream is packaged by DataOutputStream () at the time of transmission, then the different data types are written, and finally the Bytearrayoutputstream package is converted into a byte stream, which is sent through the established socket channel. This has the following two questions.

Problem one: size and end problems

PC-side devices use the x86 platform and the data is in the small-end format. The JVM virtual machine uses the big-endian format, when you read a byte in Java, such as: Call Datainputstream.read (), you can read a byte normally. However, if you want to read a multibyte data type, such as: Datainputstream.readint (), there will be data errors at the size end. The small-end format stores low-byte data in low-address storage space, while the big-endian format stores low-byte data in high-address space. In this way, the high status of the data is just upside down.

Solution Solutions

The solution to this problem is also relatively easy, and the result can be obtained by the butterfly exchange of high-status error data. For the size-end format conversion, you can first make a short-based conversion, and then the int data high and low bits to call the short conversion, the code is as follows:

    /**     * 大小端蝶形交换     *      * @param data     *            待交换的short数据     * @return 转换后的short数     */    privatestaticshortswapShortToLittleEndian(short data)    {        short ret = (short880x00FF);        ret = (short0xFFFF);        return ret;    }

The int data can then be converted to the high and low 16 bits, respectively:

 /** * size end Butterfly Swap * * @param  data * To be exchanged int * @return  converted I NT Number */ private  static  void  swapinttolittleendian  (int  data) {int  ret = Swapshorttolittleendian (() ((Data >> 16 ) & 0xffff )) | (Swapshorttolittleendian ((short ) data) << 16        );    return  ret; }

After the above two functions can be 16 bytes, 32 bytes of data into the small-format, for the 64-bit can use the same principle.
PS: May have friends on the above frequent and 0xffff/0xff to do with the calculation of some doubts, here is to say the second question, this and the operation is necessary, the following say the reason

Question two: Java implicit type conversion

In Java, for byte +-*/>> >>> << & | ^ (plus, minus, multiply, divide, shift right, left, unsigned right, bit and, bit or, bitwise XOR) operations, will be the first to convert byte to int, then the operation. This process can then lead to a variety of problems.

Solution Solutions

As you know, there are only signed numbers in Java to facilitate the processing of data. That is, the symbol is represented by the highest bit, and the remaining bits represent the actual data. In the upper-and-small-end conversions, we need to first move the low 8-bit data to a high of 8 bits, while moving the high 8-bit data to a low 8-bit. In the process of moving left, there is no doubt that the right side is automatically 0, so the result of direct shift is the result we want. But if you move right, you can get the correct result for a positive number (the highest bit is 0), but if it's a negative number (the highest bit is 1), then the high point is automatically 1 when you move right, and of course this can be solved by the operator ">>>", but there is another problem: When a byte is shifted, the system implicitly converts it to int data, and if it is negative, the high-order data is all 1.
If after the right shift does not and 0xFF do bit with, then and high data bits or stitching when the high will be directly all 1, which is why the frequent bit and operation reasons.
Comprehensive:
1. When you receive C + + unsigned data in Java, be sure to pay attention to the conversion of the size end.
2. In addition to the shift operation, it is important to note that the high-clearance zero must be eliminated after the right shift.

The above is the personal problems encountered and their own solutions, if there are more options, welcome to add!

Data conversion When Java communicates with C + + networks