I want to know the specific difference between simple TLV and BER TLV
Why the BER TLV 5F05 05 48656C6C6F is Invalid as in BER TLV the tag can have one or more consecutive bytes???
Please give some examples also ..
The BER means bearer which allows the carriying of other TLV's within
BER-TLV data object contains (TL (TLV) (TLV) with a tag field followed by a length field encoding a number.
The template, consists of one or more BER-TLV data objects, each one consisting of a tag field, a length field encoding a number and if the number is not zero, a value field.
In case its not clear feel free to contact me.
Regards
Anup
I would like to add one more thing which is related to my question -
Why the BER TLV 5F05 05 48656C6C6F is Invalid as in BER TLV the tag can have one or more consecutive bytes???
Answer is -
As in BER TLV the Tag field can be structured in following manner :
(ISO/IEC 7816 supports length fields of one, two, … up to five bytes)
In case when length of tag is 1 byte then the valid values can be -
"00" to "7F"
In case when length of tag is 2 bytes then the valid values can be -
"81" (for 1st byte) and "00" to "FF" (for 2nd byte)
In case when length of tag is 3 bytes then the valid values can be -
"82" (for 1st byte) and "0000" to "FFFF" (for 2nd + 3rd bytes)
In case when length of tag is 4 bytes then the valid values can be -
"83" (for 1st byte) and "000000" to "FFFFFF" (for 2nd + 3rd + 4th bytes)
In case when length of tag is 5 bytes then the valid values can be -
"84" (for 1st byte) and "00000000" to "FFFFFFFF" (for 2nd + 3rd + 4th + 5th bytes)
So, in BER TLV 5F05 05 48656C6C6F -> The tag is of 2 bytes length (5F05) which is wrong because if the tag is of 2 bytes length then its first byte must be "81" and 2nd byte can be any in range "00" to "FF.
Feel free to ask in case of confusion.
Related
https://learn.microsoft.com/en-us/dotnet/api/system.convert.tobase64string?view=net-5.0
It says
If an integral number of 3-byte groups does not exist, the remaining
bytes are effectively padded with zeros to form a complete group. In
this example, the value of the last byte is hexadecimal FF. The first
6 bits are equal to decimal 63, which corresponds to the base-64 digit
"/" at the end of the output, and the next 2 bits are padded with
zeros to yield decimal 48, which corresponds to the base-64 digit,
"w". The last two 6-bit values are padding and correspond to the
valueless padding character, "=".
Now,
Imagine that the byte array I send is
0
So, only one byte, namely 0
That one byte will be padded right into 000 right?
So now, we will have something like 0=== as the encoding because it takes 4 characters in base 64 encoding to encode 3 bytes.
Now, we gonna decode that.
How do we know that the original byte isn't 00, or 000, but just 0?
I must be missing something here.
So now, we will have something like 0=== as the encoding
3 padding characters is illegal. This would mean 6 bit plus padding.
And then 0 as a byte value is A in Base64, so it would be AA==.
So the first A has the first 6 bits of the 0 byte, the second A contributes the 2 remaining 0 bits for your byte, and then there are just 4 0 bits plus the padding left, not enough for a second byte.
How do we know that the original byte isn't 00, or 000, but just 0?
AA== has only 12 bits (6 bits per character) so it can only encode 1 Byte => 0
AAA= has 18 bits, enough for 2 bytes => 00
AAAA has 24 bits = 3 bytes => 000
Recently while taking some algorithm practise at leetcode i came across a solution, i understood everything except the part where the user converts an element in a string to an integer, look at the code below. Hopefully someone can explain this to me. Thanks for replies in advnace.
a := 234
b := strconv.Itoa(a)
c := int(b[0]-48) // why do we subtract 48?
48 is the code of the '0' character in the ASCII table.
Go stores strings as their UTF-8 byte sequences in memory, which maps characters of the ASCII table one-to-one to their code.
The digits in the ASCII table are listed contiguously, '0' being 48. So if you have a digit in a string, and you subtract 48 from the character's code, you get the digit as a numeric value.
Indexing a string indexes its bytes, and in your case b[0] is the first byte of the b string, which is 2. And '2' - 48 is 2.
For example:
fmt.Println('0' - 48)
fmt.Println('1' - 48)
fmt.Println('2' - 48)
fmt.Println('3' - 48)
fmt.Println('4' - 48)
This outputs (try it on the Go Playground):
0
1
2
3
4
“b” is a string “234”, a string is a slice of rune therefore b[0] is a byte/rune, in this case a value of 50 which is the decimal value of a “2” in ascii. So “c” will be 50-48=2
I am trying to add in cell data validation for a string length to be between 8 and 16 and the max byte length less than 40(UTF8 encoding).
I created a data validation using the excel active support:
Data validation(data tab -> Data Validation (between Remove Duplicates and Consolidate in excel 2016 mac)), In Settings tab, there is validation
criteria:
Validation Criteria:
Allow: Text Length
Data : between
Min : 8 & Max : 16
Though the above validation satisfies all the restrictions i have(8
For other languages(say Japanese), though the string length is being counted though physical length(Eg : "こんにちはこんにちはこんにちは", hellohellohello in Japanese), the UTF8 byte value is 45 bytes, which is the violation of the 40 bytes, thought the length is only 15.
I found "LENB" function in excel, but it is giving the value as 30(instead of 45). I think it is based on different encoding(ansi maybe)
I found the UNICODE function which gives the unicode number of the first character(12371) in the above case. But i don't see how can i get the byte value from this number(3 bytes is the value for the first character(こ)).
Any help in this regard will be greatly appreciated.
I faced the same issue and here is the solution without VBA based on the answer above + this article. Assuming you have a string in A1:
=SUM(
IF(UNICODE(MID(A1,ROW(INDIRECT("1:"&LEN(A1))),1))<128, 1,
IF(UNICODE(MID(A1,ROW(INDIRECT("1:"&LEN(A1))),1))<2048, 2,
IF(UNICODE(MID(A1,ROW(INDIRECT("1:"&LEN(A1))),1))<65536, 3, 4
))))
Don't forget to use array function (CTRL+SHIFT+ENTER) when leaving the cell :)
With the Unicode value, you can compute how many bytes a particular one will take. <128 is 1 byte, else <2048 is 2, else <65536 is 3, else 4.
This is supposed to be a low-level course, and it is only the third day of class. However, we are asked to "Write the null-terminated string 'R5' in hexadecimal, binary, and octal notations. Assume that ASCII code is used"
I have no idea where to go to learn how to do this. Any suggestions? Thanks.
NULL-terminated ASCII strings are stored with one byte per character, plus one byte for the NULL. You would therefore be printing three bytes - 'R', '5', and 0.
Look up 'R' and '5' on an ASCII chart to see what the numeric values are for those characters in ASCII. Then, write out your three bytes three different ways - one each for hexadecimal, binary and octal.
Hope that helps.
It seems like this just requires you to look up the appropriate entries from the ASCII table, which in most cases lists hex and octal and the characters themselves.
ASCII is a standard way of defining how characters are represented, and most tables will list characters against corresponding hex, decimal, and octal values. The first 128 is standard and the next 128 are the extended characters (those weird characters that don't map to an English keyboard).
If you google "ASCII table" you'll be inundated with different links. The top one I saw at www.asciitable.com appears to have everything you need - except binary.
Most of the times you're not going to see binary listed, but it's fairly academic to translate a hex value into binary - your Windows Calculator will happily do this for you.
To more directly translate your specific string you'll look up each character (including the NULL) separately and translate each individually.
Ultimately to the computer, everything is a number. To represent characters such as letters or symbols, we can agree on an encoding, or a numbering of these characters. For example, we could invent a new encoding where 1 means 'A', 2, means 'B', and so on. ASCII is one commonly used text encoding which maps characters to numbers. In this case, we are concerned with a string of 3 characters: 'R', '5', and null (a null character marks the end of a string. It is represented by the value 0. If you look in an ASCII table, you'll find that the numeric values are 82, 53, and 0.
String: R, 5, <null>
Decimal numbers: 82, 53, 0
Our normal number system is base-10, or decimal. This means that each digit represents a value ten times larger than the next (1, to 10, to 100, to 1000, etc.). Alternate bases include 8 (octal), 16 (hexadecimal), and 2 (binary). There is a straightforward way to convert between bases, although you can also easily find calculators that will do the conversion for you. You may want to review the relevant section of your textbook, or check out the Wikipedia articles. For the example of decimal 82, the hexadecimal value is 52 (this means 5*16 + 2 = 8*10 + 2). Oftentimes you will see a prefix of "0x", this is commonly used to make it clear the following digits are in base 16. (otherwise, you might think "52" refers to the decimal value 52).
Interesting. So would it be correct to say that the null-terminated string "R5" is simply "52, 35, 30" or is there a more correct format to it? Thank you for your patience. –
As I pointed out in another comment, the actual value 0 marks the end of a string, not the value 0x30, which represents a character '0' in the string. Note that the value of zero (0) is the same regardless of which base your numbers are in.
String: R, 5, <null>
Decimal : 82, 53, 0
Hexadecimal: 52, 35, 0
Question:
Is it save to get substring n characters from a text in RPG using MOVEL function which take a text with length x and store it to a variable with capacity n?
Or the only save way to get the first n character is using SUBST?
The background of the question is one of my colleague getting the first 3 characters from a database with 30 char in length is using MOVEL to a variable with length only 3 char (like truncating the rest of it). The strange way, sometimes the receive variable is showing minus character ('-'), sometimes doesn't. So I assume using MOVEL is not a safe way. I am thinking like string in C which always terminated by '\0', you need to use strcpy function to get the copy save, not assigning using = operator.
Anybody who knows RPG familiar with this issue?
MOVEL should work. RPG allows several character data types. Generally speaking, someone using MOVEL will not be dealing with null terminated strings because MOVEL is an old technique and null terminated strings are a newer data type. You can read up on the MOVEx operations and the string operations in the RPG manual. To get a better answer, please post your code, including the definitions of the variables involved.
EDIT: Example of how MOVEL handles signs.
dcl-s long char(20) inz('CORPORATION');
dcl-s short char(3) inz('COR');
dcl-s numb packed(3: 0);
// 369
c movel long numb
dsply numb;
// -369
c movel short numb
dsply numb;
*inlr = *on;
With signed numeric fields in RPG the sign is held in the zone of the last byte of the field. So 123 is X'F1F2F3' but -123 is X'F1F2D3'. If you look at those fields as character strings they will have 123 and 12L in them.
In your program you are transferring something like "123 AAAAAL" to a 3 digit numeric field so you get X'F1F2F3' but because the final character is X'D3' that changes the result to have a zone of D i.e. X'F1F2D3'
You anomaly is dependent on what the 30th character contains. If it is } or any capital letter J to R then you get a negative result. [It doesn't matter whether the first 3 characters are numbers or letters because it is only the second half of the byte, the digit, that matters in your example.]
The IBM manuals say:
If factor 2 is character and the result field is numeric, a minus zone is moved into the rightmost position of the result field if the zone from the rightmost position of factor 2 is a hexadecimal D (minus zone). However, if the zone from the rightmost position of factor 2 is not a hexadecimal D, a positive zone is moved into the rightmost position of the result field. Other result field positions contain only numeric characters.
Don