What does the statement "hexadecimal matches cleanly with modulo 8 word sizes, such as 8, 16, 32, and 64 bits" mean?
Since a single hex digit can represent exactly 4 bits of binary data, any word size that's a multiple of 4 can be exactly represented with a fixed number of hex digits.
And every word size that's a multiple of 8 (i.e. the common ones) can be represented with a number of digits that's a multiple of 2:
8 bits can store values from 00 to FF
16 bits can store values from 0000 to FFFF
32 bits can store values from 00000000 to FFFFFFFF
...
All 2-digit hex numbers can be represented in 8 bits and all 8 bit values can be represented in 2 hex digits. If a hex editor displays some value as CA FE BA BE you can easily grasp that it's 4 bytes and thus 32 bits. Getting that information from the decimal 3405707966 is not quite as trivial (no matter how you group the digits: there's no nice "byte boundaries" in that representation).
If you compare this with decimal, the same isn't true. For example, 8 bits can represent values from 0 to 255 (decimal). So you need up to 3 digits in decimal to represent 8-bit values. But there are 3-digit decimal values that you can't represent in 8 bits: 256 (or anything higher than that) doesn't map onto 8 bits. So the mapping isn't perfect for decimal numbers.
Related
I was checking out the difference between char vs varchar2 from google. I came across a word LEADING LENGTH in this link . THERE it was written that
Suppose you store the string ‘ORATABLE’ in a CHAR(20) field and a VARCHAR2(20) field. The CHAR field will use 22 bytes (2 bytes for leading length). The VARCHAR2 field will use 10 bytes only (8 for the string, 2 bytes for leading length).
Q1:How does the char field will use 22 bytes if the string is of 8 characters if (1 byte = 1 char)?
Q2 What is the LEADING LENGTH ? why it does occupy 2 bytes?
The CHAR() datatype pads the string with characters. So, for 'ORATABLE', it looks like:
'ORATABLE '
12345678901234567890
The "leading length" are two bytes at the beginning that specify the length of the string. Two bytes are needed because one byte is not enough. Two bytes allow lengths up to 65,535 units; one byte would only allow lengths up to 255.
The important point both CHAR() and VARCHAR2() use the same internal format, so there is little reason to sue CHAR(). Personally, I would only use it for fixed-length codes, such as ISO country codes or US social security numbers.
Whenever i tried to convert HEX (12 11 80 64 29 86) to ASCII, it print out unreadable characters.
12 11 80 64 29 86 - > d)
What is this d) and how can i make it readable?
I'm working with a GPS unit and it send me data through TCP.
Here is a full message
$$ ▒▒d)▒▒▒U071121.000,A,2047.6419,N,09702.6721,E,0.11,185,080718,,*0C|1.0|1409|0000|0001,0000,0000,028A|019E00010C819D45|1E|0006F055|08i-
I need unreadable characters before U071121 in HEX as it represent the device ID.
Here is an ascii table with printable and non printable characters: https://theasciicode.com.ar/ascii-printable-characters/capital-letter-v-uppercase-ascii-code-86.html
Here is the hex version: https://www.rapidtables.com/convert/number/hex-to-ascii.html
I suspect that your 3rd and 6th characters are outside the ascii character set.
Note that hex is base 16. 12 in hex is 18 in decimal.
I'm trying to assemble proper track data given a CVC3 and a bunch of positional parameters. But the EMV C-2 Kernel book is about as obtuse as you could imagine (would it kill somebody to include an example!?!). Can anyone help work this example:
9f62 - pcvc3(t1) - Position of CVC3 in track1: 0x38 (4-6?)
9f63 - punatc(t1) - Unpredictable Number Track1 Pos: 0x3C6 (2-3 7-10?)
9f64 - natc(t1) - Digits in track1 ATC: 4
9f65 - pcvc3(t2) - Position of CVC3 in track2: 0x38 (4-6)
9f66 - punatc(t2) - Unpredictable Number Track2 Pos: 0x3C6 (2-3 7-10?)
9f67 - Digits in track2 ATC: 4
After successful checksum generation:
9f61 - track2 CVC3 - 2EF4
9f60 - track1 CVC3 - 609B
9f36 - ATC - 1E47
assuming the discretionary data field starts out as all 0s, how does it end up? The spec says this:
Convert the binary encoded CVC3 (Track2) to the BCD encoding of the
corresponding number expressed in base 10. Copy the q least significant digits of the
BCD encoded CVC3 (Track2) in the eligible positions of the 'Discretionary Data' in
Track 2 Data. The eligible positions are indicated by the q non-zero bits in
PCVC3(Track2).
I read that as:
CVC3 = 0x609B = 24731 (so copy 731? What does BCD have to do with this? Or are they just saying "copy the 731 as bcd encoded to the byte array"?)
yes you are correct it is rather obtuse. you are correct that you would convert your p values (pCVC3, and PUNATC) to binary. (0011 1000, 0011 1100 0110 for your track1 p values) you then right align the proper values with the discretionary data. example
Bxxxxxxxxxxxxxxxx^ /^14111014010000000000
....000000000000000000CCC000
....00000000000000AAAA000UU0
so you say that you CVC3 for track 1 is 609B which is 24,731, since you PCVC3 is asking for only 3 characters youd set 731 in. your ATC is 1E47 which is 7,751. your PUNATC is asking for 4 digits so you'd use 7751. FYI... if the ATC is lower than the requested characters you'd pad with 0's. Your unpredictable number is even more tricky... so you make a 4 byte random number. convert it to a uint (base 10) and then mark the 8 most significant bytes as 0. example. lets say your random 4 bytes is 29A6 06AE. in base 10 that is 698,746,542. mark out the first 8 characters with 0. and you are left with 000,000,002. you'd place 02 in for you unpredictable number placment.. so.. all that said your track would look like this
Bxxxxxxxxxxxxxxxx^ /^14111014017751731020
the last character is equal to the length of the unpredicatable number (numeric) digits. which was 02.. so the last digit is 2 making your final track data
%Bxxxxxxxxxxxxxxxx^ /^1411014017751731022;
track2 is very similar. good luck with it. I understand your frustrations with this. :)
I'm wondering if it is possible to represent a number as a sequence of bits, each having approximately the same significance, such that if we flip one of the bits, the overall value does not change by much.
For example, we can use sequences of 4-bits, where each group represents a value from 0 to 15 and the overall value is the sum of all these values.
0110 0101 1101 1010 1011 → 6 + 5 + 13 + 10 + 11 = 45
and now flipping any bit can only incur in a maximum difference of 8 in the final value.
Some drawbacks obviously exist with this approach:
values have multiple representations, with some values having more representations than other ones (for example, there are 39280 distinct representations for the number 38, and only 1 for the number 0);
the amount of values that can be represented is greatly reduced (this representation allows for integers from 0 to 75, while 20 bits could normally represent 220 ~ 1 million different integers).
Are there any resources I can find concerning this problem? I can't seem to find anything online, but maybe I'm not searching with the right keywords. What other alternatives exist to my approach? Do they improve on its disadvantages?
I am faced with the task of sending ISO 8583 Rev 93 messages and am using openiso8583.net. The company that is consuming my messages gave message samples and I am unclear about the following Field attributes:
Special Characters
Alphabetic & Numeric Characters
Alphabetic & Special Characters
Number & Special Characters
Alphabetic, Numeric, & Special Characters
Here is the example:
Signon Reply
0810822000000200000004000000000000000501130427000005F0F00001
NUM |FLDNAME |FIELD DESCRIPTION |LEN |T|FIELD VALUE
-----|--------|-------------------------------|----|-|--------------------------
N/A |MSGTYPE |MESSAGE TYPE |F2 |H|0810`
N/A |BITMAP1 |FIRST BITMAP |B8 |H|8220000002000000`
1 |BITMAP2 |SECOND BITMAP |B8 |H|0400000000000000`
7 |MISDTMDT|TRANSMISSION DATE AND TIME |F5 |H|0501130427`
11 |MISDSTAN|SYSTEM TRACE AUDIT NUMBER |F3 |H|000005`
39 |MISDRSPC|RESPONSE CODE |F2 |C|00` <------?
70 |MISDNMIC|NETWORK MANAGEMENT INFO CODE |F2 |H|0001`
First, take a look at the message bytes:
0810822000000200000004000000000000000501130427000005*F0F0*0001
My question is how the two bytes { 0xF0, 0xF0 } translates to "00". If the company was sending ASCII, I would expect "00" to be { 0x30, 0x30 }. BCD is used for Numeric values but I can't seem to figure out how character values are being encoded.
Here is the description for field 39:
039:
Network Response Code
Attributes:
an 2*
Description:
A field that indicates the result of a previous related request. It will indicate
approval or reason for rejection if not approved. It is also used to indicate to the
device processor whether or not machines that are capable of retaining the customer's
card should do so.
Format:
In transaction replies, the response code must contain one of the following values
with their corresponding meanings. For debit/host-data-capture 0220 / 0420 messages, a
response code of '00' must be returned to indicate the transaction was approved. For
EBT transactions, please refer to section 4.8 EBT Transaction Receipt Requirements.
an2 means Alphabetic & Numeric Characters
Bitmap 1 is 64 bits
Bitmap 2 is 64 bits
Msg Type is 4 bytes
Field 7 is Numeric 4-bit BCD (Packed unsigned) 10, 5 bytes
Field 11 is Numeric 4-bit BCD (Packed unsigned) 6, 3 bytes
Field 39 is an 2, I assume 2 bytes
Field 70 is Numeric 4-bit BCD (Packed unsigned) 3, 2 bytes
Any clues or pointers would be greatly appreciated. Maybe someone knows of some encoding I clearly do not or can give a general explenation of how characters are encoded for ISO 8583 Rev 93. I do realize that each company can have different implementations though.
I hate answering my own questions quickly but...I just found the answer.
EBCDIC
I guess not being a programmer in the days of punch cards slowed me down on this one
0xF0 = '0'