How convert() function works in WTX?
I have code like this. CONVERT(input element,"|||||||||||||||||||||||||||||||| |""#$%&'()*+,-.|0123456789:;|=|?#ABCDEFGHIJKLMNOPQRSTUVWXYZ|\||_|abcdefghijklmnopqrstuvwxyz{|}||" )
Convert has 2 arguments. First byes to be replaced. Second replaceable bytes. Syntax : convert(bytes_to_replace, replaceable_bytes).
It is usually used to convert data from ASCII to EBCDIC or from EBCDIC to ASCII .
The ordinal for each byte in bytes_to_converts points the nth byte in the replacement bytes.
e.g. if there is a A in bytes_to_convert, it gets replaced by the 65th byte in the replacement bytes
Related
Is there any routine available ? I didn´t find any
Thanks
Under the assumption that you want to read a binary file that contains bytes for printable characters like "A"=65 and nonprintable characters like "ESC"=27 something like this might help?
integer(kind=selected_int_kind(1)), dimension(1000) :: vector
open(unit=10,file='data.data', access='stream', form='unformatted')
i=1
read(unit=10, iostat=ios) vector(i)
do while(ios==0)
i=i+1
read(unit=10, iostat=ios) vector(i)
enddo
For simplicity I assumed that the length of the vector is at most 1000. The vector will now contain the decimal representation of the ASCII characters in the input file.
I come across the below statement while studying about HTML Character Sets and Character Encoding :
Since ASCII used 7 bits for the character, it could only represent 128
different characters.
When we convert any decimal value from the ASCII character set to its binary equivalent it comes down to a 7-bits long binary number.
E.g. For Capital English Letter 'E' the decimal value of 69 exists in ASCII table. If we convert '69' to it's binary equivalent it comes down to the 7-bits long binary number 1000101
Then, why in the ASCII Table it's been mentioned as a 8-bits long binary number 01000101 instead of a 7-bits long binary number 1000101 ?
This is contradictory to the statement
Since ASCII used 7 bits for the character, it could only represent 128
different characters.
The above statement is saying that ASCII used 7 bits for the character.
Please clear my confusion about considering the binary equivalent of a decimal value. Whether should I consider a 7-bits long binary equivalent or a 8-bits long binary equivalent of any decimal value from the ASCII Table? Please explain to me in an easy to understand language.
Again, consider the below statement :
Since ASCII used 7 bits for the character, it could only represent 128
different characters.
According to the above statement how does the number of characters(128) that ASCII supports relates to the fact that ASCII uses 7 bits to represent any character?
Please clear the confusion.
Thank You.
In most processors, memory is byte-addressable and not bit-addressable. That is, a memory address gives the location of an 8-bit value. So, almost all data is manipulated in multiples of 8 bits at a time.
If we were to store a value that has by its nature only 7 bits, we would very often use one byte per value. If the data is a sequence of such values, as text might be, we would still use one byte per value to make counting, sizing, indexing and iterating easier.
When we describe the value of a byte, we often show all of its bits, either in binary or hexadecimal. If a value is some sort of integer (say of 1, 2, 4, or 8 bytes) and its decimal representation would be more understandable, we would write the decimal digits for the whole integer. But in those cases, we might lose the concept of how many bytes it is.
BTW—HTML doesn't have anything to do with ASCII. And, Extended ASCII isn't one encoding. The fundamental rule of character encodings is to read (decode) with the encoding the text was written (encoded) with. So, a communication consists of the transferring of bytes and a shared understanding of the character encoding. (That makes saying "Extended ASCII" so inadequate as to be nearly useless.)
An HTML document represents a sequence of Unicode characters. So, one of the Unicode character encodings (UTF-8) is the most common encoding for an HTML document. Regardless, after it is read, the result is Unicode. An HTML document could be encoded in ASCII but, why do that? If you did know it was ASCII, you could just as easily know that it's UTF-8.
Outside of HTML, ASCII is used billions—if not trillions—of times per second. But, unless you know exactly how it pertains to your work, forget about it, you probably aren't using ASCII.
I'm using RISC-V and I am limited to using just and, or, xori, addition, subtraction, multiplication, division of integer values.
So for instance, the letter "a" will be represented as 97 and "aa" will be represented as 24929, and so on. The UI converts binary sequence into decimal representation, and I cannot directly modify n-th bit.
Is there anyway I can find a simple, general equation of converting from lowercase to uppercase the decimal representation of a maximum of 8 letter sequence of Strings?
Also, I forgot to add, I can't partition the string into individual letters either. Maybe it's possible, but I don't know how to do it.
Letters or characters are usually represented as byte values, which are easier to read in hexadecimal. This can be seen if you convert 97 and 24929 to hex.
You did not mention the system which was used to encode the characters; mentioning the value for one character is not definitive. Assuming your letters are encoded as ASCII, find an ASCII table and figure out the DIFFERENCE between upper- and lowercase character codes.
Use this knowledge to design an algorithm to transform lowercase character codes to uppercase.
A good uppercase conversion algorithm will not modify characters that are not lowercase letters.
This can be extended to SIMD if you are careful to avoid carries between bytes if you need to add or subtract.
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.
I'm looking for a shorthand solution to storing an md5 hash inside of a MySQL table, as string data. I had the idea that base256 could reduce the length of the string by half, down to a 16 digit string instead of 32 digits of hex. So I take hex and divide it up into chunks of two digits programatically then convert each set of two digits to ASCII. For example:
4cf5f5941a02573dc007e60442f5358a
is shortened to
Lõõ”W=ÀæBõ5Š
and it's OK if these characters don't print properly - I just need to store them. Would MySQL accept that sort of ASCII data into a text field without complaining?
MySQL will accept these values, but you must be very carefull when writing them - I strongly suggest binding parameters.
You might want to look into COMPRESS() and UNCOMPRESS() as an alternative:
INSERT INTO ... SET hashcode=COMPRESS('4cf5f5941a02573dc007e60442f5358a');
and
SELECT UNCOMPRESS(hashcode) AS hashcode FROM ... WHERE
might do the trick more readable