I want to Bitwise-XOR a string (actually its binary representation) with a KEY.
The result of the operation should be represented as HEX.
What I have:
'a' - the UTF-8 String to be changed.
'ACF123456' - the key in HEX.
Result seen as BIGINT:
select CONV(HEX('a'), 16, 10) ^ CONV('ACF123456', 16, 10);
Result seen as HEX:
select CONV( CONV(HEX('a'), 16, 10) ^ CONV('ACF123456', 16, 10), 10, 16);
Questions:
Is the conversion above done correctly?
What happens if the string is too long (i.e instead of 'a' we have 'a veeeeeery long string')? It seems that the conv() function has a limitation (is it the 64-bit precision from the documentation)? And besides the XOR operator ^ has also a limitation, related to the nr. of bits of the returned result. Any solutions that work for any string (a stored procedure is allowed)?
Thanks.
Your conversions look fine to me.
And as you point out, both CONV() and ^ have indeed a 64-bits precision.
2^64 = 16^16, therefore strings of more than 16 hexadecimal digits should convert to integers larger than 2^64. However, such strings will be brutally (silently) truncated from the left when attempting to convert them to integers.
The point of my solution here is to slice such strings. Obviously, the result may not be displayed as an integer, but only as a string representation.
Let #input be your "string to be changed" and #key, your "key".
Assign HEX(#input) to #hex_input. No problem here since HEX() works with strings.
Slice #hex_input into 16 hexadecimal digit long strings, starting from the right
Likewise, slice #key into 16 digit long strings.
Compute the X-OR of each 64-bit slice of #hex_input with each 64-bit slice of #key, starting from the right. Use CONV(#slice, 16, 10). If either #hex_input or #key has less slices than the other string, then X-OR the remaining slices of the other string with 0.
Convert each 64-bit number resulting from the X-OR in point 4. back into an hexadecimal string with UNHEX().
Reassemble the resulting slices. This is your result.
A three-columns TEMPORARY table could be used as an array to store slices of #hex_input, #mask and the resulting slices.
Put this all together into a stored procedure, and voilà!
You sound like you have some skills in MySQL, you should be able to translate the above into real code. But I'll be happy to help if you need further guidance.
Related
I see the following code:
binary scan "xyz" H* var
It puzzles me: binary scan is supposed to scan a binary stream and construct string type variables, but here it is "xyz" ...?
I did the following experiment inside tclsh:
% puts $var
78797a <== what is this?
% binary scan $var #1H y <== I mean to get "y"
1
% puts $y <== but I get "3"?
3
I am lost.
Could you explain what is going on?
Does it help to know that the hexadecimal value of the character 'x' is 0x78? Or that binary scan \x78\x79\x7a H* var2 is identical to your example? The examples in the 'binary scan' manual page under the 'H' conversion code explain it pretty well, I think.
In your code:
binary scan "xyz" H* var
The binary string is xyz, which is three bytes that are the ASCII values for x, y and z. We then ask for the var variable to be given a sequence hex digits of the scanned bytes in big endian order (very much the right thing for dealing with strings, BTW!) with twice as many hex digits as there are bytes in the binary string (because *). Let's double check with what the documentation says:
The data is turned into a string of count hexadecimal digits in high-to-low order represented as a sequence of characters in the set “0123456789abcdef”. The data bytes are scanned in first to last order with the hex digits being taken in high-to-low order within each byte. Any extra bits in the last byte are ignored. If count is *, then all of the remaining hex digits in string will be scanned. If count is omitted, then one hex digit will be scanned. For example,
binary scan \x07\xC6\x05\x1f\x34 H3H* var1 var2
will return 2 with 07c stored in var1 and 051f34 stored in var2.
Now, there are three bytes in xyz so there are six digits in 78797a. The first two hex digits, 78 are the the hex for the ASCII version of x (check for yourself), and similarly for 79 and 7a.
When you then do:
binary scan $var #1H y
you move the internal cursor into the string to the byte for the ASCII for 8 (because zero-based indexing), \x38, and because there's no count given to the H, it gets the first hex digit of 38 (i.e., 3) and puts that in the y variable.
To actually retrieve the y, you can just use string index or string range on the original binary string (as all Tcl's string commands work just fine on binary data). Or you use string range to get the hex digits out of var and binary format to convert back:
binary format H* [string range $var 2 3]
It's probably not a good idea to binary scan the results of binary scan. It's totally legal to do so, but the results are going to be unlikely to illuminate.
What is the difference between 65 and the letter A in binary as both represent same bit level information?
Basically, a computer only understand numbers, and not every numbers: it only understand binary represented numbers, ie. which can be represented using only two different states (for example, 1 and 2, 0V and 5V, open and close, true or false, etc.).
Unfortunately, we poor humans doesn't really like reading zeros and ones... So, we have created some codes, to use number like if they were characters: one of them is called ASCII (American Standard Code for Information Interchange), but there is also some others, such as Unicode. The principle is simple: all the program have to do is manipulating numbers, what any CPU does very well, but, when it comes to displaying these data, the display represent them as real characters, such as 'A', '4', '#', or even a space or a newline.
Now, as soon as you are using ASCII, the number 65 will represent the letter 'A'. All is a question of representation: for example, the binary number 0bOOOO1111, the hexadecimal one 0x0F, the octal one 017 and the decimal number 15 all represent the same number. It's the same for letter 'A': think of ASCII as a base, but instead of using the base 2 (binary), 8(octal), 10(decimal) or 16(hexadecimal), to display numbers, it's used in a complete different manner.
To answer your question: ASCII 'A' is hexadecimal 0x41 is decimal 65 is octal 0101 is binary 0b01000001.
Every character is represented by a number. The mapping between numbers and characters is called encoding. Many encodings use for the letter A the number 65. Since in memory there are no special cells for characters or numbers, they are represented the same way, but the interpretation in any program could be very different.
I may be misunderstanding the question and if so I apologise for getting it wrong
But if I'm right I believe your asking what's the difference between a char and int in binary representation of the value 65 which is the ascii decimal value for the letter A (in capital form)
First off we need to appreciate data types which reserve blocks of memory in the ram modules
An interget is usually 16 bits or more if a float or long (in c# this declaration is made by stating uint16, int16, or int32, uint32 so on, so forth)
A character is an 8 bit memory block
Therefore the binary would appear as follows
A byte (8 bits) - char
Decimal: 128, 64, 32, 16, 8, 4, 2, 1
Binary: 01000001
2 bytes (16 bit) - int16
Binary; 0000000001000001
Its all down to the size of the memory block reserved based on the data type in the variable declaration
I'd of done the decimal calculations for the 2 bit but I'm on the bus at the moment
First of all, the difference can be in size of the memory (8bits, 16bits or 32bits). This question: bytes of a string in java
Secondly, to store letter 'A' you can have different encodings and different interpretation of memory. The ASCII character of 'A' in C can occupy exact one byte (7bits + an unused sign bit) and it has exact same binary value as 65 in char integer. But the bitwise interpretation of numbers and characters are not always the same. Just consider that you can store signed values in 8bits. This question: what is an unsigned char
My instructor stated that "an octal byte consists of 6 bits". I am having difficulty understanding why this is, as an octal digit consists of 3 binary bits. I also do not understand the significance of an octal byte being defined as '6 bits' as opposed to some other number.
Can anyone explain why this is, if it is in fact true, or point me to a useful explanation?
This is all speculation and guesswork, since none of this is in any way standard terminology.
An 8-bit byte can be written as two digits of hexadecimals, because each digit expresses 4 bits. The largest such byte value is 0xFF.
By analogy, two digits of octals can express 2 × 3 = 6 bits. Its largest value is 077. So if you like you can call a pair of two octals an "octal byte", but only if you will also call an 8-bit byte a "hexadecimal byte".
In my personal opinion neither notion is helpful or useful, and you'd be best of just to say how many bits your byte has.
Like #Kerrek SB I'd have to guess the same.
Tell him an octal byte is two octal nibbles, that should sort him out.
Two hexadecimal digits is an 8 bit byte, so each four bits were called a nibble.
as for wiki : The byte is a unit of digital information that most commonly consists of 8 bits. The bit is a contraction of binary digit. The bit represents a logical state with one of two possible values. These values are most commonly represented as either "1" or "0".
so byte is a set of bunch of bits. to be specific of 8 bits.
we see that the definition doesnt say anything about dec oct hex and other notations of integer number.
indeed byte and integer number is not the same. so where
does it start ?
if we type bits of byte like so 01001010 we can find that
we can map 1-to-1 this object to binary notation
of integer numbers 01001010.
(byte)01001010 --> (binary integer) 01001010
the two objects look the same but actually is just mapping.
now we work with integer number instead of abstract object "byte". an integer
number can be designated via different notations like : dec, binary, hex, oct etc.
notation like octal(hex,dec etc) is just a method of designation of integer number. it does not influence the nature of initial byte object.
byte has 8 bits whatever notation is used.
ISO/IEC 2382-1:1993 says:
1.The number of bits in a byte is usually 8.
2.Octet is Byte that consists of eight
Bits
I have created an SQL database using Java. I have a table created which has two columns, the first being a big integer which increments, the second I have tried defining it as a char, varchar and binary.
But I'm still not getting the desired functionality. Say I try and store a hex number 0a into the char column and I get an error. I appended 0x to the beginning and it seems to store, but when I print out the contents it is blank. Or in some cases I get characters such as '/' or '?'. I also tried using SQL explorer and it gives me the same result viewing the table,
My problem is I need to store an eight character hex string such as eb8d4ee6.
Could someone please advise me of how this can be done?
See http://dev.mysql.com/doc/refman/5.5/en/hexadecimal-literals.html
MySQL supports hexadecimal values,
written using X'val', x'val', or 0xval
format, where val contains hexadecimal
digits (0..9, A..F). Lettercase of the
digits does not matter. For values
written using X'val' or x'val' format,
val must contain an even number of
digits. For values written using 0xval
syntax, values that contain an odd
number of digits are treated as having
an extra leading 0. For example, 0x0a
and 0xaaa are interpreted as 0x0a and
0x0aaa.
In numeric contexts, hexadecimal
values act like integers (64-bit
precision). In string contexts, they
act like binary strings, where each
pair of hex digits is converted to a
character:
You probably should store the Hex number in an integer column. You can then convert back to hex when selecting using the HEX() function.
E.g.,
INSERT INTO MyTable (`MyIntegerColumn`) VALUES (0xeb8d4ee6);
You can use a Json column:
And use JSON.stringify(hex) to insert and you can always get the result via select and compare too
Just wondering on how I would go about converting binary to hexadecimal??
Would I first have to convert the binary to decimal and then to hexadecimal??
For example, 101101001.101110101010011
How would I go about converting a complex binary such as the above to hexadecimal?
Thanks in advance
Each 4 bits of a binary number represents a hexadecimal digit. So the best way to convert from binary to hexadecimal is to pad the binary number with leading zeroes so that the number of bits is divisible by four.
Then you process four bits at a time and convert them to a single hexadecimal digit:
0000 -> 0
0001 -> 1
0010 -> 2
....
1110 -> E
1111 -> F
No, you don't convert to decimal and then to hexadecimal, you convert to a numeric value, and then to hexadecimal.
(Decimal is also a textual representation of a number, just like binary and hexadecimal. Although decimal representation is used by default, a number doesn't have a textual representation in itself.)
As a hexadecimal digit corresponds to four binary digits you don't have to convert the entire string to a number, you can do it four binary digits at a time.
First fill up the binary number so that it has full groups of four digits:
000101101001.1011101010100110
Then you can convert each group to a number, and then to hexadecimal:
0001 0110 1001.1011 1010 1010 0110
169.BAA6
Alternatively, you can split the number into the two parts before and after the period and convert those from binary. The part before the period can be converted stright off, but the part after has to be padded to be correct.
Example in C#:
string binary = "101101001.101110101010011";
string[] parts = binary.Split('.');
while (parts[1].Length % 4 != 0) {
parts[1] += '0';
}
string result =
Convert.ToInt32(parts[0], 2).ToString("X") +
"." +
Convert.ToInt32(parts[1], 2).ToString("X");
You could simply have a small hash table, or other mapping converting each quadruplet of binary digits (as a string, assuming that's your input) into the corresponding hex digit (0 to 9, A to F) for the output string. You'll have to bunch the input bits up by 4, left-padding before the '.' and right-padding after it, with 0 in both cases, as needed.
So...:
locate the '.'
left of the '.', bunch by 4, left-padding the last bunch, going leftwards: in your example, 1001 leftmost, then 0110, finally 0001 (left-padding), that's it;
ditto to the right -- in your example 1011, then 1010, then 1010, finally 0110 (right-padding)
each bunch of 4 binary digits, via a hash or other form of hashing, turns into the hex digit to put in that place in the output string.
Want some pseudo-code for it, e.g., Python?
The simplest approach, especially if you already can convert from binary digits to internal numeric representation and from internal numeric representation to hexadecimal digits, is to go binary->internal->hex. I say internal and not decimal, because even though it may print as decimal, it is actually being stored internally in binary format. That said, it is possible to go straight from one to the other. This does not apply to your specific example, but in many cases when converting from binary to hex, you can go four digits at a time, and simply lookup the corresponding hex values in a table. There are all sorts of ways to convert.
BIN to HEX
Binary and hex are natively compatible. Just group 4 binary digits(bits) and substitute the corresponding HEX-digit.
More reference here:
http://en.wikipedia.org/wiki/Hexadecimal#Binary_conversion