How can I convert the string 00 00 EF 01 00 00 00 00 00 00 to text?
I googled and found a online tool which can convert binary to text only.
This values are in HEX - This tool
does hex as well, you can always transalte HEX to decimal and then take their ASCII value...
I created a tool few years ago that can convert/encode strings. Hope you'll find it useful.
I'm assuming here the text you've supplied is "as is", with spaces separating the hex digit pairs.
You can convert each hex value with, e.g.:
byte.Parse("EF", System.Globalization.NumberStyles.AllowHexSpecifier)
So you can convert the whole to a byte array:
var byteArray = "0A 0A 0A".Split(' ').Select(s => byte.Parse(s, System.Globalization.NumberStyles.AllowHexSpecifier)).ToArray();
However, you don't specify what character encoding your hex stream represents. Once you've got your byte array, you'll need to convert it as necessary.
Related
I'm trying to decode the JPG file, the entire header part is correctly read. During the reading of the photo body itself (SOS, 0xFFDA) at some point, the function for finding the correspondence in the Huffman table goes into an infinite loop. If you look at the file in the hex editor, you can find the following sequence of bytes at the error location:
7F FF 00 61
FF 00 => FF
7F FF 61
that in binary code
0111 1111 1111 1111 0110 0001
The first bit has already been used by the past MCU, now it's 15 'ones' in a row and then zero. In the corresponding Huffman table, the maximum code is 8 ones and one zero. I concluded that the byte 7F was just filled with ones until the end. But this is not the end of the file. How can I find out when I need to skip a byte, and when not?
Algorithm of decode AC coefficient was not very clear. I changed loop condition from (index != 63) to (index <= 63) because of EOB that hit the 64th element of MCU and everything began to work.
https://www.w3.org/Graphics/JPEG/itu-t81.pdf (page 106)
I think, I should be able to get the byte length of a string by:
Buffer.byteLength('äáöü') // returns 8 as I expect
Buffer.byteLength('あいうえお') // returns 15, expecting 10
However, when getting the byte length with a spreadsheet program (libreoffice) using =LENB("あいうえお"), I get 10 (which I expect)
So, why do I get for 'あいうえお' a byte length of 15 rather than 10 using Buffer.byteLength?
PS.
Testing the "あいうえお" on these two sites, I get two different results
http://bytesizematters.com/ returns 10 bytes
https://mothereff.in/byte-counter returns 15 bytes
What is correct? What is going on?
node.js is correct. The UTF-8 representation of the string "あいうえお" is 15 bytes long:
E3 81 82 = U+3042 'あ'
E3 81 84 = U+3044 'い'
E3 81 86 = U+3046 'う'
E3 81 88 = U+3048 'え'
E3 81 8A = U+304A 'お'
The other string is 8 bytes long in UTF-8 because the Unicode characters it contains are below the U+0800 boundary and can each be represented with two bytes:
C3 A4 = U+E4 'ä'
C3 A1 = U+E1 'á'
C3 B6 = U+F6 'ö'
C3 BC = U+FC 'ü'
From what I can see in the documentation, LibreOffice's LENB() function is doing something different and confusing:
For strings which contain only ASCII characters, it returns the length of the string (which is also the number of bytes used to store it as ASCII).
For strings which contain non-ASCII characters, it returns the number of bytes required to store it in UTF-16, which uses two bytes for all characters under U+10000. (I'm not sure what it does with characters above that, or if it even supports them at all.)
It is not measuring the same thing as Buffer.byteLength, and should be ignored.
With regard to the other tools you're testing: Byte Size Matters is wrong. It's assuming that all Unicode characters up to U+FF can be represented using one byte, and all other characters can be represented using two bytes. This is not true of any character encoding. In fact, it's impossible. If you encode every characters up to U+FF using one byte, you've used up all possible values for that byte, and you have no way to represent anything else.
I have a buffer that is filled with data and begins with < Buffer 52 49 ...>
Assuming this buffer is defined as buf, if I run buf.readInt16LE(0) the following is returned:
18770
Now, the binary representation of hex values 52 and 49 are:
01010010 01001001
If I were to convert the first 15 bits to decimal, omitting the 16th bit for two's complement I would get the following:
21065
Why didn't my results give me the value of 18770?
18770 is 01001001 01010010 which is your 2 bytes reversed, which is what the readInt*LE functions are going to do.
Use readInt16BE.
You could do this: parseInt("0x" + buf.toString("hex")). Probably a lot slower but would do in a pinch.
There is a dynamic library for 64-bit linux, it contains many functions compiled from from C++ code. The code is not open source, but I have an idea how one of the functions shoul look like. It contains mathematical expression and I would like to change one of the constants in this expression.
I have some programming skills, but never looked into compiled objects and executable. The relevant part of assembly code obtained by objdump -RDC command is below. The constant of interest should be of type double and it seems it is used in multiplication command in line 7e1cc.
7e1b8: 00
7e1b9: f2 0f 59 74 24 78 mulsd 0x78(%rsp),%xmm6
7e1bf: f2 41 0f 59 f0 mulsd %xmm8,%xmm6
7e1c4: f2 0f 58 ce addsd %xmm6,%xmm1
7e1c8: f2 0f 58 ca addsd %xmm2,%xmm1
7e1cc: f2 0f 59 0d fc 0e 0c mulsd 0xc0efc(%rip),%xmm1 # 13f0d0 <typeinfo name for RestorableCreator<Model>+0x90>
7e1d3: 00
7e1d4: 48 81 c4 88 00 00 00 add $0x88,%rsp
7e1db: 66 0f 28 c1 movapd %xmm1,%xmm0
7e1df: c3 retq
I'd like to know how to find the position of this constant in the file, convert my constant to hex format and replace the value in the file to my hex value. Could anyone explain how to do this? Also suggestions about proper tools would be really valuable.
The constant is at address 0xc0efc(%rip) where %rip is the address of the next instruction, meaning 0x7e1d4. So the address is: 0xc0efc + 0x7e1d4 = 0x13F0D0 (objdump even prints that for you).
Now, examine the headers of your binary using objdump -h. That will list all the sections along with virtual addresses and file offsets. Find which section the address falls into, and calculate how far into the section it is, then add the file offset. Now use a hex editor to fetch the 8 bytes representing your double from that offset. Turn it into human-readable form by whatever means you want, for example by a trivial C program that just casts a byte array to double and prints it.
I'm looking for the COBOL alternative of Visual Basic's MID Function. The thing I need to do is take from 8 strings the first 5 letters and concatenate them.
I'm using Fujitsu COBOL.
Many thanks,
Yvan
Paxdiablo has given a couple of valid ways to do it. Another way would be to use reference modification in addition to the STRING verb. Complete program example follows:
IDENTIFICATION DIVISION.
PROGRAM-ID. EXAMPLE9.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 STRINGS.
05 STRING1 PIC X(10) VALUE 'AAAAAAAAAA'.
05 STRING2 PIC X(10) VALUE 'BBBBBBBBBB'.
05 STRING3 PIC X(10) VALUE 'CCCCCCCCCC'.
05 STRING4 PIC X(10) VALUE 'DDDDDDDDDD'.
05 STRING5 PIC X(10) VALUE 'EEEEEEEEEE'.
05 STRING6 PIC X(10) VALUE 'FFFFFFFFFF'.
05 STRING7 PIC X(10) VALUE 'GGGGGGGGGG'.
05 STRING8 PIC X(10) VALUE 'HHHHHHHHHH'.
05 STRING-OUT PIC X(40) VALUE SPACES.
PROCEDURE DIVISION.
STRING STRING1(1:5) STRING2(1:5) STRING3(1:5) STRING4(1:5)
STRING5(1:5) STRING6(1:5) STRING7(1:5) STRING8(1:5)
DELIMITED BY SIZE
INTO STRING-OUT
DISPLAY STRING-OUT
GOBACK.
This cuts down on the verbosity quite a bit and captures the concatenation in a single statement. Best advice is to read up on the STRING verb. There are a number of innovative ways it can be used.
COBOL does not provide an exact analogue to the BASIC MID statement. You can accomplish similar operations by using some combination of STRING, UNSTRING, INSPECT and reference modification. An example of a reference modification is: SOME-VARIABLE-NAME(1:5) - the 1:5 bit specifies a substring of SOME-VARIABLE-NAME starting with the first character for a length of 5 characters. The modifiers may themselves be numeric variables. The STRING and UNSTRING verbs provide a number of features that can be quite powerful.
In general though, COBOL is not particularly good at string manipulation (some might say its not particularly good at anything - but I would disagree with that statement).
I think it goes something like this:
WORKING STORAGE SECTION.
01 NORMAL-STRING-A PIC X(80)
01 NORMAL-STRING-B PIC X(80)
01 NORMAL-STRING-C PIC X(80)
01 NORMAL-STRING-D PIC X(80)
01 NORMAL-STRING-E PIC X(80)
01 SUB-STRING.
05 FIVE PIC X(5)
05 REST PIC X(75)
01 TWENTY-FIVE-A.
05 FIVE-A PIC X(5).
05 FIVE-B PIC X(5).
05 FIVE-C PIC X(5).
05 FIVE-D PIC X(5).
05 FIVE-E PIC X(5).
01 TWENTY-FIVE-B PIC X(25).
PROCEDURE DIVISION.
MOVE NORMAL-STRING-A TO SUB-STRING.
MOVE FIVE TO FIVE-A.
MOVE NORMAL-STRING-B TO SUB-STRING.
MOVE FIVE TO FIVE-B.
MOVE NORMAL-STRING-C TO SUB-STRING.
MOVE FIVE TO FIVE-C.
MOVE NORMAL-STRING-D TO SUB-STRING.
MOVE FIVE TO FIVE-D.
MOVE NORMAL-STRING-E TO SUB-STRING.
MOVE FIVE TO FIVE-E.
MOVE TWENTY-FIVE-A TO TWENTY-FIVE-B.
Then, your string is in TWENTY-FIVE-B.
You know, I can't imagine why people thought COBOL was verbose :-)
On a more serious note, I think you can do something along these lines to achieve the same result (you may have to fiddle with the start and length parameters, it's been a while since I did any serious COBOL):
WORKING STORAGE SECTION.
01 STRING-A PIC X(80)
01 STRING-B PIC X(80)
01 STRING-C PIC X(80)
01 STRING-D PIC X(80)
01 STRING-E PIC X(80)
01 TWENTY-FIVE PIC X(25).
PROCEDURE DIVISION.
MOVE STRING-A(1:5) TO TWENTY-FIVE( 1:5).
MOVE STRING-B(1:5) TO TWENTY-FIVE( 6:5).
MOVE STRING-C(1:5) TO TWENTY-FIVE(11:5).
MOVE STRING-D(1:5) TO TWENTY-FIVE(16:5).
MOVE STRING-E(1:5) TO TWENTY-FIVE(21:5).
This substring examples page shows a few variations. An example:
* Task3 suffix(xStr,Length)
* Extract the last Length number of chars from a string
* Solution - use reference modification with start of substring
* defined as the FullStringLength - SubStringLength + 1
* In this example we get the last 13 characters.
MOVE 13 TO StrLength
DISPLAY "Task3 = " xStr2((StrSize - StrLength) + 1:StrLength)
WORKING STORAGE SECTION.
01 NORMAL-STRING-A PIC X(80)
01 NORMAL-STRING-B PIC X(80)
01 NORMAL-STRING-C PIC X(80)
01 NORMAL-STRING-D PIC X(80)
01 NORMAL-STRING-E PIC X(80)
01 TWENTY-FIVE-A.
05 FIVE-A PIC X(5).
05 FIVE-B PIC X(5).
05 FIVE-C PIC X(5).
05 FIVE-D PIC X(5).
05 FIVE-E PIC X(5).
01 TWENTY-FIVE-B REDEFINES TWENTY-FIVE-A PIC X(25).
PROCEDURE DIVISION.
MOVE NORMAL-STRING-A TO FIVE-A
MOVE NORMAL-STRING-B TO FIVE-B
MOVE NORMAL-STRING-C TO FIVE-C
MOVE NORMAL-STRING-D TO FIVE-D
MOVE NORMAL-STRING-E TO FIVE-E