I want to convert Binary in String like my name is Harshit and if I convert my name into binary, I get '01001000 01100001 01110010 01110011 01101000 01101001 01110100', it's a binary form of my name.
Now I want to convert this binary again in the 'Harshit' string.
how we can do this in apex.
Related
Original byte value in base16 BINARY format -
7e-c2-8c-c2-8a-c7-61-60-34-b7-0e-de-c2-28-9e-b3-08-a6-c3-93-74-99-34-09-48-0c-60-e3-96-47-04-e3
After converting it to VARCHAR - 7EC28CC28AC7616034B70EDEC2289EB308A6C39374993409480C60E3964704E3
I need to convert it back to BINARY and for this I used the TO_BINARY('7EC28CC28AC7616034B70EDEC2289EB308A6C39374993409480C60E3964704E3') function,
but it returns 7EC28CC28AC7616034B70EDEC2289EB308A6C39374993409480C60E3964704E3
instead of the desired 7e-c2-8c-c2-8a-c7-61-60-34-b7-0e-de-c2-28-9e-b3-08-a6-c3-93-74-99-34-09-48-0c-60-e3-96-47-04-e3.
Note - TO_BINARY(string,'base16') doesn't work
You want to strip the hyphens, and use TO_BINARY on 'HEX' input type
SELECT
'7e-c2-8c-c2-8a-c7-61-60-34-b7-0e-de-c2-28-9e-b3-08-a6-c3-93-74-99-34-09-48-0c-60-e3-96-47-04-e3' as tb_b16_str
,replace(tb_b16_str, '-') as no_hyphen
,to_binary(no_hyphen, 'HEX') as now_as_bin
,base64_encode(now_as_bin) as now_as_base64
;
TB_B16_STR
NO_HYPHEN
NOW_AS_BIN
NOW_AS_BASE64
7e-c2-8c-c2-8a-c7-61-60-34-b7-0e-de-c2-28-9e-b3-08-a6-c3-93-74-99-34-09-48-0c-60-e3-96-47-04-e3
7ec28cc28ac7616034b70edec2289eb308a6c39374993409480c60e3964704e3
7ec28cc28ac7616034b70edec2289eb308a6c39374993409480c60e3964704e3
fsKMworHYWA0tw7ewiieswimw5N0mTQJSAxg45ZHBOM=
if we take the BASE64, and paste that into notepad++ and BASE64 decode that, and save that as a bin file and open in a hex editor, we can see sure enough now_as_bin is correct decoded as expected..
You already have a binary:
So thinking about this more, you are already successfully coverting the data to a Snowflake binary:
SELECT '7EC28CC28AC7616034B70EDEC2289EB308A6C39374993409480C60E3964704E3' as hex_str
,system$typeof(hex_str)
,TO_BINARY(hex_str) as now_as_binary
,system$typeof(now_as_binary);
The result you don't like the look of, it's a Snowflake binary.
HEX_STR
SYSTEM$TYPEOF(HEX_STR)
NOW_AS_BINARY
SYSTEM$TYPEOF(NOW_AS_BINARY)
7EC28CC28AC7616034B70EDEC2289EB308A6C39374993409480C60E3964704E3
VARCHAR(64)[LOB]
7ec28cc28ac7616034b70edec2289eb308a6c39374993409480c60e3964704e3
BINARY(8388608)[LOB]
How to export back to teradata:
Or you are really looking for "how to convert a binary to Teradata formatting string for exporting from Snowflake to Teradata"
So the step broken down:
SELECT
'7EC28CC28AC7' as hex_str
,TO_BINARY(hex_str) as now_as_binary
,hex_encode(now_as_binary) as back_to_hex
,REGEXP_REPLACE(back_to_hex, '(..)','\\1-') as made_chunky
,RTRIM(made_chunky, '-') as wanted
;
gives:
HEX_STR
NOW_AS_BINARY
BACK_TO_HEX
MADE_CHUNKY
WANTED
7EC28CC28AC7
7ec28cc28ac7
7EC28CC28AC7
7E-C2-8C-C2-8A-C7-
7E-C2-8C-C2-8A-C7
and that can be mashed together like:
SELECT
TO_BINARY('7EC28CC28AC7') as now_as_binary
,RTRIM(REGEXP_REPLACE(hex_encode(now_as_binary), '(..)','\\1-'), '-') as made_chunky
;
NOW_AS_BINARY
MADE_CHUNKY
7ec28cc28ac7
7E-C2-8C-C2-8A-C7
How to convert decimal value to hexadecimal in SQL SERVER..
example I have ID Decimal(20,0) value(141021750051366541) to convert into hexadecimal something like this 06ca02dc04426208
If your number fits into bigint, you can simply format(cast(#yourNumber as bigint), 'x')
Why when I use the command in SQL Server 2005
select convert(varbinary(16),N'123')
results 0x310032003300 and not 1111011?
Basically each letter of '123' gets converted to it's UCS-2(basically the ASCII value padded to make it a double byte) value in the three double bytes of 0x3100, 0x3200, 0x3300, and concatenated together in a varbinar.
Hopefully that answers why you see this behavior. If you convert to an int first you may see what you were perhaps hoping for instead:
select convert(varbinary(16),cast(N'123' as int))
produces hex value 0x0000007B which in binary is 1111011
See http://www.asciitable.com/ the entry for numeric 3, the hex representation is 0x33 which corresponds to the same entry in unicode: http://www.ssec.wisc.edu/~tomw/java/unicode.html (this pattern does not necessarily hold true for all ASCII/unicode characters, but does for the 10 integers).
Consider you have several patterns of dates P1 - Pn.
Some of them are simple like P1 - all Mondays, P2 - all Tuesdays; others are more complex like P4 - all working days etc.
For custom array of dates (V1, V2) I have to create the shortest result string, as it is shown on the picture:
For any array we have to create string which will represent dates in array. The simplest method is to create string like 1.5.2013, 2.5.2013, 3.5.2013 ... But the result string will be very long.
Using several predefined patterns we can create shorter result string.
For result string I use following rules:
Single date format: DD.MM.YYYY (10 characters)
Enumeration (dates and patterns): comma and space (2 characters)
Interval of dates: DD.MM.YYYY-DD.MM.YYYY (21 characters)
Interval of pattern names: Px-Py (5 characters)
Special words: except (6 characters)
Examples of result strings:
V1 using P4 pattern:
P4 except 01.05.2013-03.05.2013, 09.05.2013, 10.05.2013, 16.05.2013, 17.05.2013 (80 characters)
V1 using Pn pattern:
Pn 06.05.2013-08.05.2013, 13.05.2013-15.05.2013, 20.05.2013-24.05.2013, 27.05.2013-31.05.2013 (94 characters)
V1 using best patterns match:
P1-P3 01.05.2013-19.05.2013, P4 20.05.2013-31.05.2013 (54 characters)
The main goal is to create the shortest result string. As I understand we can achieve this by finding the best matching pattern/patterns.
Currently I'm trying to adapt knapsack problem and longest common subsequence problem, but I'm not sure if it is the right direction.
I would appreciate any ideas.
updated
Thanks to Jan Dvorak for his extra short description of my problem:
The goal is to describe V using a predefined dictionary (P1..Pn and all intervals and single dates) where intersection, union and subtraction are all allowed and each operation and atom have a predefined cost (number of characters in result string).
After long time of searching we finally found solution which is very close to what we want.
http://www.fpz.unizg.hr/traffic/index.php/PROMTT/article/view/1287
Thanks for all how participated.
This is just a suggestion but if you want a really short string that represent the arrays of dates, you could solve this problem in a totally different way, this way is very simply and efficient.
Let 1 represent a day "seleceted" and let 0 represent a day "unselected", then you can construct a binary number that represent the custom date arrays in a month, for example, for the V1 case you can generate this binary number:
V1 = 0000011100001110000111110011111
So the first 0 represent that the date 1.5.2013 is "unselected", the next 0 represent that the date 2.5.2013 is "unselected", etc. If you separate this number in 8 bits groups (dividing the binary number in bytes) then you can create this byte array:
V1(starting in May 1, 2013) = 00000111 - 00001110 - 00011111 - 00111110 (4 bytes)
With this method you are representing the V1 using just 4 bytes, this is the only info you need if you know that V1 start on the date 1.5.2013, so you need to store the initial date as well, so you can represent the month and year using just 3 bytes, so for instance the May 2013 date can be represented in this way:
May = 5th month so 5 in binary is 101
2013 in binary is 11111011101
So using 3 bytes you can represent May 2013 as this:
0000101 00000111 11011101
[ 5 ] [ 2013 ]
So you can represent V1 as this
V1= 0000101 - 00000111 - 11011101 00000111 - 00001110 - 00011111 - 00111110
[Month] [ Year ] [ V1 custom array of dates ]
So V1 can be totally represented using just 7 bytes!!
If you need a String instead of a byte array, then you can convert this byte array into a
Base64 String so V1 can be represented as the string
V1 in Base64 is Cg+6Dhw+Pg== (using just 12 characters!!)
In the case of V2:
V2 = 0000101 - 00000111 - 11011101 11111111 - 11111111 - 11111111 - 11101110
[Month] [ Year ] [ V2 custom array of dates ]
V2 in Base64 is Cg+7////bg== (using just 12 characters again!!)
With this method you know that a month custom array of dates info can be represented in 7 bytes (or 12 characters if you use the base 64 String).
To store the custom array info in a year you just need:
3 bytes for the start month and year, plus 365/8 = 45.625 (rounded to 46 bytes), that is 49 bytes!! for the whole year, that in base 64 has a maximum length of 69 characters!!!
This is simple to implement, easy to maintain in code, better than a complex pattern matching algorithm, this smell like a good solution to me. I hope that this recommendation fits your requirement.
It seems that SQL Server does not accept numbers formatted using any particular locale.
It also doesn't support locales that have digits other than 0-9.
For example, if the current locale is bengali, then the number 123456789 would come out as "১২৩৪৫৬৭৮৯". And that's just the digits, nevermind what the digit grouping would be.
But the same problem happens for numbers in the Invariant locale, which formats numbers as "123,456,789", which SQL Server won't accept.
Is there a culture that matches what SQL Server accepts for numeric values? Or will i have to create some custom "sql server" culture, generating rules for that culture myself from lower level formatting routines?
If i was in .NET (which i'm not), i could peruse the Standard Numeric Format strings. Of the format codes available in .NET:
c (Currency): $123.46
d (Decimal): 1234
e (Exponentional): 1.052033E+003
f (Fixed Point): 1234.57
g (General): 123.456
n (Number): 1,234.57
p (Percent): 100.00 %
r (Round Trip): 123456789.12345678
x (Hexadecimal): FF
Only 6 accept all numeric types:
c (Currency): $123.46
d (Decimal): 1234
e (Exponentional): 1.052033E+003
f (Fixed Point): 1234.57
g (General): 123.456
n (Number): 1,234.57
p (Percent): 100.00 %
r (Round Trip): 123456789.12345678
x (Hexadecimal): FF
And of those only 2 generate string representations, in the en-US locale anyway, that would be accepted by SQL Server:
c (Currency): $123.46
d (Decimal): 1234
e (Exponentional): 1.052033E+003
f (Fixed Point): 1234.57
g (General): 123.456
n (Number): 1,234.57
p (Percent): 100.00 %
r (Round Trip): 123456789.12345678
x (Hexadecimal): FF
Of the remaining two, fixed is dependant on the locale's digits, rather than the number being used, leaving General g format:
c (Currency): $123.46
d (Decimal): 1234
e (Exponentional): 1.052033E+003
f (Fixed Point): 1234.57
g (General): 123.456
n (Number): 1,234.57
p (Percent): 100.00 %
r (Round Trip): 123456789.12345678
x (Hexadecimal): FF
And i can't even say for certain that the g format won't add digit groupings (e.g. 1,234).
Is there a locale that formats numbers in the way SQL Server expects? Is there a .NET format code? A java format code? A Delphi format code? A VB format code? A stdio format code?
latin-numeral-digits
The SQL Server specifications for constants are describing the acceptable formats in T-SQL expressions and batches:
integer constants are represented by a string of numbers that are not
enclosed in quotation marks and do not
contain decimal points. Integer
constants must be whole numbers; they
cannot contain decimals.
decimal constants are represented by a string of numbers that are not
enclosed in quotation marks and
contain a decimal point.
float and real constants are represented by using scientific
notation.
money constants are represented as string of numbers with an optional
decimal point and an optional currency
symbol as a prefix. Money constants are
not enclosed in quotation marks. SQL
Server does not enforce any kind of
grouping rules such as inserting a
comma (,) every three digits in
strings that represent money. Commas
are ignored anywhere in the specified
money literal.
To indicate whether a number is positive or negative, apply the + or - unary operators to a numeric constant. This creates a numeric expression that represents the signed numeric value. Numeric constants use positive when the + or - unary operators are not applied.
The good news is that client applications don't need to worry about these requirements. Client applications should pass numeric values as #parameters, not as T-SQL literal constants.