When exporting data from google analytics to bigquery it returns hex data as 8.2886383989219471e+47 but it should be a "0x" hex string
when formatting it as a float "%.2f" the resulting number is
828863839892194670000000000000000000000000000000.00 which seems to be some precision is being lost from that number
How would I be able to get this number as a correct string?
Related
Is it possible to decode a Base64 encoded string in DB2 database?
I was able to decode the string in SQL Server by casting to XML.
I am running db2 in Linux server
z/OS:
BASE64ENCODE and BASE64DECODE
Last Updated: 2022-08-23
The BASE64ENCODE and BASE64DECODE helper REST functions complete Base64 encoding or decoding of the provided text.
Tip: The sample HTTP user-defined functions are intended to be used within Db2 SQL applications to access remote non-Db2 REST-based services through SQL statements. Do not confuse them with Db2 native REST services, which supports using a REST-based interface to interact with Db2 data from web, mobile, and cloud applications.
The schema is DB2XML.
text
Specifies the text to encode or decode. For BASE64ENCODE, this argument is provided as a VARCHAR(2732) value and the function returns a Base64-encoded string. For BASE64DECODE, this argument is provided as a Base64-encoded VARCHAR(4096) value and the function returns the data as binary.
IBMi:
BASE64DECODE scalar function Last Updated: 2022-05-03
The BASE64DECODE function returns a character string that has been Base64 decoded. Base64 encoding is widely used to represent binary data as a string.
The schema is SYSTOOLS.
character-string
A character string in CCSID 1208 that is currently Base64 encoded. The length cannot exceed 4096 characters.
The result of the function is a varying length character for bit data string that contains character-string after being Base64 decoded.
Example
Decode a binary string that was originally X'1122334455'. The result is the original value.
VALUES SYSTOOLS.BASE64DECODE('ESIzRFU=');
-- encoding
values regexp_replace (xmlserialize (xmlelement (name "a", blob (X'1122334455')) as varchar (20)), '^<a>(.*)</a>$', '$1')
1
ESIzRFU=
-- decoding (hex function use is just to get a string representation of a binary value)
values hex (xmlcast (xmltext ('ESIzRFU=') as blob (20)))
1
1122334455
I'm currently trying to read from a CSV files ( separated with semicolon ';') with decimal numbers formatted with a comma(,) as a decimal separator instead of a dot (.).
i.e: the number 12356.12 is stored as 12356,12.
In the source's projection, what would be the correct format to read the value correctly?
The format should in Java Decimal Format
If your CSV file's columnDelimiter is a comma (','), your first concern is how to avoid your number data won't be treated as different columns. Since your number data is stored as 12356,12, so my suggests as below :
Change the columnDelimiter as | or other special characters.
2.Set escape char. Please see this description:
In addition, 12356,12 can't be identified as Decimal format in ADF automatically. And no such mechanism o turn , into .. So I think you need to transfer data as string temporary. Then convert it into Decimal in your destination with java code.
True answer is in the comments: In the copy job the culture can be defined, which influences the decimal separator. Go to "mapping" > "Type conversion settings" > "culture" and chose en-us, de-de or whatever works for you. Be aware that this will also influence other types like dates.
We are attempting to import a SAS7BDAT file into a SQL Server database.
The only issue we're running into is that source decimal values are being read as float.
Using a command line tool named dsread, we found an option that:
Converting the IEEE floating-point numeric values in the SAS7BDAT file to their decimal representation may cause a loss of precision. To get a lossless representation of the data, use the /l flag:
sashelp> dsread /v /l prdsale
ACTUAL,PREDICT,COUNTRY,...
0x0000000000e88c40,0x0000000000908a40,CANADA...
0x0000000000388f40,0x0000000000907240,CANADA...
0x0000000000008340,0x0000000000708a40,CANADA...
0x0000000000108440,0x0000000000a88040,CANADA...
0x0000000000808440,0x0000000000308440,CANADA...
0x0000000000a08d40,0x0000000000607e40,CANADA...
...etc...
The numerics are output as eight hexadecimal bytes (16 digits) giving the internal floating-point representation, which can then be used to reconstruct the exact same value in the receiving software. Use /L to get the bytes in big-endian order
Running some tests, we can see that the decimal value -1.457263 is being represented by the value 0xcbbbea01f350f7bf when we use that /L flag. What we haven't been able to figure out is, how can we convert that hexadecimal value into a SQL Server decimal value?
We've tried many variants, including:
select CONVERT(decimal, convert(varbinary,'0xcbbbea01f350f7bf',1))
but that results in:
Msg 8115, Level 16, State 6, Line 17
Arithmetic overflow error converting varbinary to data type numeric.
If 0xcbbbea01f350f7bf = -1.457263, then it looks like that's a IEEE double-precision floating point number with a big endian byte order.
So reverse the bytes (or get it to export in little endian instead)
0xcbbbea01f350f7bf -> 0xbff750f301eabbcb
Then convert it to a float. You can use CLR or there's a TSQL function you can try here:
Unpacking a binary string with TSQL
Then convert it to a decimal.
select convert(decimal(36,17), dbo.[fnBinaryFloat2Float]( 0xbff750f301eabbcb ), 3)
Which, you can see has preserved a closer approximation to the floating point value
-1.45726299999999998
Is there a way to reconstruct the "exact same value" with no differences?
Then leave the data as float(53) which is exactly the same data type from the source, and don't convert it to decimal at all. decimal and float each store finite subsets of the rational numbers, and many numbers can be exactly represented in either system. But some float values don't have an exact match in decimal, and vice versa.
I am using bro to read bytes directly of the payload of a packet.
I have a string value "\x10" and I want to get the decimal value of off that.
I know that bro support directly printing hex to decimal:
print 0x10;
Question is, how do I convert that string similarly to its integer version?
The best you can do is strip off the "\x" portion, and run it through 2 BIFs:
bytestring_to_count(hexstr_to_bytestring("10"));
I am trying to configure a GPS device to my systems. The GPS device send the data packet to my IP in the following format :
$$�W��¬ÿÿÿÿ™U042903.000,A,2839.6408,N,07717.0905,E,0.00,,230111,,,A*7C|1.2|203|0000÷
I am able to extract the latitude, longitude and other information but I am not able to extract the Tracker ID out of the string.
According to the manual the ID is in hex format.And the format of the packet is
$$<L(2 bytes)><ID(7 bytes)><command (2 bytes)><data><checksum (2 bytes)>\r\n
I don't know what to do with it, I have tried converting this to hex..but it didn't work.
Any help will be greatly appreciated.
How about more information? What GPS? What interface (USB, serial)? What language are you working in?
Your data certainly looks odd. In my experience with GPS data, it's generally alphanumeric and separators, but it looks like you have either a corrupt string or non-alphanumeric values.
Update based upon additional information you provided:
The GPRS manual you supplied explains the format:
$$ - 2 bytes - in ASCII code (Hex code: 0x24)
L - 2 bytes - in hex code
ID 7 bytes - in the format of hex code.
For example, if ID is 13612345678, then it will be shown as follows:
0x13, 0x61, 0x23, 0x45, 0x67, 0x8f, 0xff.
command - 2 bytes - hex code
If I understand correctly, the gibberish characters after $$ and before the data field are not printable ASCII characters. They're actual numeric values, provided one byte at a time. If you convert each byte to a hexadecimal-formatted string and display it, you should see what I mean.
I don't remember my PHP well, but I think the ID could be formed into a hexadecimal-formatted string by something like this:
$s = GetYourGPRSStringFromWherever()
$sID = sprintf("0x%02x%02x%02x%02x%02x%02x%02x", $s[4], $s[5], $s[6],
$s[7], $s[8], $s[9], $s[10]);
(also, strip out or ignore any 0xFF values, as per the documentation's example)