Re: Odd text encoding

[Stephen Price]

Exciting times for all of us. It's been a fun ride so far, with more in
store. :)

On Sat, 12 Sep 2015 at 13:17 Ken Schaefer <k...@adopenstatic.com> wrote:

> Well, there are no guarantees about what we’ll see in the future, but
> here’s some stats for what’s come in the past:
>
> http://pages.experts-exchange.com/processing-power-compared/
>
> e.g. from 1956 through to 2015 has seen a trillion-fold increase in FLOPs.
> Something that would have been a 5000 year problem in 1956 probably would
> been solved a decade ago.
>
>
>
> To Greg’s point – storage access speeds have also been increasing pretty
> quickly. I believe Samsung showed off a 16TB 2.5” flash drive recently,
> with a demo of 48 of these in a server, providing 768TB of storage, and 2m
> IOPS. That’s only going to get faster and faster over time.
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Bec C
> *Sent:* Friday, 11 September 2015 4:59 PM
>
>
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Odd text encoding
>
>
>
> I get your point Ken but is power really increasing at such a rate?
>
> On Friday, 11 September 2015, Ken Schaefer <k...@adopenstatic.com> wrote:
>
> And what would those numbers have looked like 2 years ago? 4 years ago? 10
> years ago?
>
>
>
> Assuming computing power doubles every 18-24 months, then that 5444 years
> will become a lot less, relatively quickly.
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Keogh
> *Sent:* Friday, 11 September 2015 10:15 AM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Odd text encoding
>
>
>
> but because they were concerned about the possibility of running out of
> bigint values. (Clearly it’s a pity more maths isn’t taught at schools).
>
>
>
> My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63
> non-stop it will take 5444 years -- *GK*
>
>

Re: Odd text encoding

[Bec C]

I get your point Ken but is power really increasing at such a rate?

On Friday, 11 September 2015, Ken Schaefer <k...@adopenstatic.com> wrote:

> And what would those numbers have looked like 2 years ago? 4 years ago? 10
> years ago?
>
>
>
> Assuming computing power doubles every 18-24 months, then that 5444 years
> will become a lot less, relatively quickly.
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com
> <javascript:_e(%7B%7D,'cvml','ozdotnet-boun...@ozdotnet.com');> [mailto:
> ozdotnet-boun...@ozdotnet.com
> <javascript:_e(%7B%7D,'cvml','ozdotnet-boun...@ozdotnet.com');>] *On
> Behalf Of *Greg Keogh
> *Sent:* Friday, 11 September 2015 10:15 AM
> *To:* ozDotNet <ozdotnet@ozdotnet.com
> <javascript:_e(%7B%7D,'cvml','ozdotnet@ozdotnet.com');>>
> *Subject:* Re: Odd text encoding
>
>
>
> but because they were concerned about the possibility of running out of
> bigint values. (Clearly it’s a pity more maths isn’t taught at schools).
>
>
>
> My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63
> non-stop it will take 5444 years -- *GK*
>

Re: Odd text encoding

[罗格雷格博士]

Ah but the issue is how many rows you can write into a table. That's a bit more 
work than a for loop :-)

Regards

Greg

Dr Greg Low
SQL Down Under
+61 419201410
1300SQLSQL (1300775775)

On 11 Sep 2015, at 5:16 pm, Greg Keogh 
> wrote:

Assuming computing power doubles every 18-24 months, then that 5444 years will 
become a lot less, relatively quickly.

I didn't mention that counting to 2^63 is eminently parallelizable, so lets 
divide up a small fraction of the free internet computing power on the problem 
and see how long it takes. I don't have any figures to even begin a rough 
calculation -- GK

Re: Odd text encoding

[Greg Keogh]

>
> Assuming computing power doubles every 18-24 months, then that 5444 years
>> will become a lot less, relatively quickly.
>>
>
I didn't mention that counting to 2^63 is eminently parallelizable, so lets
divide up a small fraction of the free internet computing power on the
problem and see how long it takes. I don't have any figures to even begin a
rough calculation -- *GK*

RE: Odd text encoding

[Ken Schaefer]

Well, there are no guarantees about what we’ll see in the future, but here’s 
some stats for what’s come in the past:
http://pages.experts-exchange.com/processing-power-compared/
e.g. from 1956 through to 2015 has seen a trillion-fold increase in FLOPs. 
Something that would have been a 5000 year problem in 1956 probably would been 
solved a decade ago.

To Greg’s point – storage access speeds have also been increasing pretty 
quickly. I believe Samsung showed off a 16TB 2.5” flash drive recently, with a 
demo of 48 of these in a server, providing 768TB of storage, and 2m IOPS. 
That’s only going to get faster and faster over time.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Bec C
Sent: Friday, 11 September 2015 4:59 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Odd text encoding

I get your point Ken but is power really increasing at such a rate?

On Friday, 11 September 2015, Ken Schaefer 
<k...@adopenstatic.com<mailto:k...@adopenstatic.com>> wrote:
And what would those numbers have looked like 2 years ago? 4 years ago? 10 
years ago?

Assuming computing power doubles every 18-24 months, then that 5444 years will 
become a lot less, relatively quickly.

From: 
ozdotnet-boun...@ozdotnet.com<javascript:_e(%7B%7D,'cvml','ozdotnet-boun...@ozdotnet.com');>
 
[mailto:ozdotnet-boun...@ozdotnet.com<javascript:_e(%7B%7D,'cvml','ozdotnet-boun...@ozdotnet.com');>]
 On Behalf Of Greg Keogh
Sent: Friday, 11 September 2015 10:15 AM
To: ozDotNet 
<ozdotnet@ozdotnet.com<javascript:_e(%7B%7D,'cvml','ozdotnet@ozdotnet.com');>>
Subject: Re: Odd text encoding

but because they were concerned about the possibility of running out of bigint 
values. (Clearly it’s a pity more maths isn’t taught at schools).

My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63 
non-stop it will take 5444 years -- GK

Re: Odd text encoding

[Thomas Koster]

It is strange that base-64 encoding is even used here at all. Surely
proper binary data types have been available in relational databases
since the dark ages?
--
Thomas Koster


On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
> That was my first reaction too. Haven't spent time staring at base64
> encoding for a long time. Knew someone would recognise it though. The brains
> trust comes through again!
>
> Regards
>
> Greg
>
> Dr Greg Low
> SQL Down Under
> +61 419201410
> 1300SQLSQL (1300775775)
>
> On 10 Sep 2015, at 3:55 pm, Stephen Price <step...@perthprojects.com> wrote:
>
> How did you get my Azure certificate? wtf??
>
> Seriously though, the trailing == on the end (plus the overall look) makes
> it look exactly like an Azure publish certificate.
>
> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>>
>> Perfect thanks Thomas.
>>
>> I'll just have to add a base64 decode function and I should be fine.
>>
>> Regards,
>>
>> Greg
>>
>> Dr Greg Low
>>
>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913
>> fax
>> SQL Down Under | Web: www.sqldownunder.com
>>
>> -Original Message-
>> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
>> On Behalf Of Thomas Koster
>> Sent: Thursday, 10 September 2015 10:33 AM
>> To: ozDotNet <ozdotnet@ozdotnet.com>
>> Subject: Re: Odd text encoding
>>
>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>> > This one’s driving me crazy and I thought the brains trust might have
>> > an idea.
>> >
>> > Here’s a value that’s stored in an ntext column in a SQL Server DB:
>> > H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
>> > GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
>> > RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
>> > S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
>> > vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
>> > zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
>> > txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
>> > vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
>> > 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
>> > 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
>> > x6lrjS6f1vK359184V9pkluuCgoAAA==
>> >
>> > Somehow, that’s apparently meant to be either a) an XML file, or b) a
>> > GZipped XML file.
>>
>> echo "H4s" | base64 -d | gunzip
>>
>> 

Re: Odd text encoding

[Mark Hurd]

Note that the original XML would have been smaller than the base64
compressed text if you removed the unused namespaces :-) (Of course it
presumably would have compressed to smaller again.)

-- 
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)


On 10 September 2015 at 15:32, Nelson <nelson.honey...@gmail.com> wrote:
> Stephen,
>
> That base64 encoding - see https://en.wikipedia.org/wiki/Base64
> the == at the end is for padding.
>
>
> base64 is a common way to encode binary data in plaintext string (gzip in
> this our case here)
>
>
> Regards,
>
> Nelson Chan
>
> On 10 September 2015 at 15:55, Stephen Price <step...@perthprojects.com>
> wrote:
>>
>> How did you get my Azure certificate? wtf??
>>
>> Seriously though, the trailing == on the end (plus the overall look) makes
>> it look exactly like an Azure publish certificate.
>>
>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>>>
>>> Perfect thanks Thomas.
>>>
>>> I'll just have to add a base64 decode function and I should be fine.
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>> Dr Greg Low
>>>
>>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913
>>> fax
>>> SQL Down Under | Web: www.sqldownunder.com
>>>
>>> -Original Message-
>>> From: ozdotnet-boun...@ozdotnet.com
>>> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Thomas Koster
>>> Sent: Thursday, 10 September 2015 10:33 AM
>>> To: ozDotNet <ozdotnet@ozdotnet.com>
>>> Subject: Re: Odd text encoding
>>>
>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com>
>>> wrote:
>>> > This one’s driving me crazy and I thought the brains trust might have
>>> > an idea.
>>> >
>>> > Here’s a value that’s stored in an ntext column in a SQL Server DB:
>>> > H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
>>> > GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
>>> > RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
>>> > S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
>>> > vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
>>> > zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
>>> > txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
>>> > vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
>>> > 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
>>> > 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
>>> > x6lrjS6f1vK359184V9pkluuCgoAAA==
>>> >
>>> > Somehow, that’s apparently meant to be either a) an XML file, or b) a
>>> > GZipped XML file.
>>>
>>> echo "H4s" | base64 -d | gunzip
>>>
>>> 
>
>



-- 
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)

Re: Odd text encoding

[Davy Jones]

Probably because binary data was easy to put in and easy to get out, but what 
you put in is not what you get out.
There are also performance implications with binary data, it's usually more 
secure to store as base64 in a varchar(max) or text.
Absolutely no reason to store in an unicode column.
Davy

Sent from my iPhone

> On 10 Sep 2015, at 09:47, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
> 
> The data was stored by Biztalk, and of course it shoved binary data into an 
> ntext data type column. The next two questions are:
> 
> 1. Why put base 64 encoded data into an ntext (unicode) column when such a 
> limited range of values can be generated?
> 2. Why use a deprecated data type (ntext) in the first place?
> 
> I'm sure that both questions are above my paygrade :-)
> 
> Regards
> 
> Greg
> 
> Dr Greg Low
> SQL Down Under
> +61 419201410
> 1300SQLSQL (1300775775)
> 
>> On 10 Sep 2015, at 5:10 pm, Thomas Koster <tkos...@gmail.com> wrote:
>> 
>> It is strange that base-64 encoding is even used here at all. Surely
>> proper binary data types have been available in relational databases
>> since the dark ages?
>> --
>> Thomas Koster
>> 
>> 
>>> On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>>> That was my first reaction too. Haven't spent time staring at base64
>>> encoding for a long time. Knew someone would recognise it though. The brains
>>> trust comes through again!
>>> 
>>> Regards
>>> 
>>> Greg
>>> 
>>> Dr Greg Low
>>> SQL Down Under
>>> +61 419201410
>>> 1300SQLSQL (1300775775)
>>> 
>>> On 10 Sep 2015, at 3:55 pm, Stephen Price <step...@perthprojects.com> wrote:
>>> 
>>> How did you get my Azure certificate? wtf??
>>> 
>>> Seriously though, the trailing == on the end (plus the overall look) makes
>>> it look exactly like an Azure publish certificate.
>>> 
>>>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>>>> 
>>>> Perfect thanks Thomas.
>>>> 
>>>> I'll just have to add a base64 decode function and I should be fine.
>>>> 
>>>> Regards,
>>>> 
>>>> Greg
>>>> 
>>>> Dr Greg Low
>>>> 
>>>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913
>>>> fax
>>>> SQL Down Under | Web: www.sqldownunder.com
>>>> 
>>>> -Original Message-
>>>> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
>>>> On Behalf Of Thomas Koster
>>>> Sent: Thursday, 10 September 2015 10:33 AM
>>>> To: ozDotNet <ozdotnet@ozdotnet.com>
>>>> Subject: Re: Odd text encoding
>>>> 
>>>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>>>>> This one’s driving me crazy and I thought the brains trust might have
>>>>> an idea.
>>>>> 
>>>>> Here’s a value that’s stored in an ntext column in a SQL Server DB:
>>>>> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
>>>>> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
>>>>> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
>>>>> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
>>>>> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
>>>>> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
>>>>> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
>>>>> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
>>>>> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
>>>>> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
>>>>> x6lrjS6f1vK359184V9pkluuCgoAAA==
>>>>> 
>>>>> Somehow, that’s apparently meant to be either a) an XML file, or b) a
>>>>> GZipped XML file.
>>>> 
>>>> echo "H4s" | base64 -d | gunzip
>>>> 
>>>> 

Re: Odd text encoding

[罗格雷格博士]

The data was stored by Biztalk, and of course it shoved binary data into an 
ntext data type column. The next two questions are:

1. Why put base 64 encoded data into an ntext (unicode) column when such a 
limited range of values can be generated?
2. Why use a deprecated data type (ntext) in the first place?

I'm sure that both questions are above my paygrade :-)

Regards

Greg

Dr Greg Low
SQL Down Under
+61 419201410
1300SQLSQL (1300775775)

> On 10 Sep 2015, at 5:10 pm, Thomas Koster <tkos...@gmail.com> wrote:
> 
> It is strange that base-64 encoding is even used here at all. Surely
> proper binary data types have been available in relational databases
> since the dark ages?
> --
> Thomas Koster
> 
> 
>> On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>> That was my first reaction too. Haven't spent time staring at base64
>> encoding for a long time. Knew someone would recognise it though. The brains
>> trust comes through again!
>> 
>> Regards
>> 
>> Greg
>> 
>> Dr Greg Low
>> SQL Down Under
>> +61 419201410
>> 1300SQLSQL (1300775775)
>> 
>> On 10 Sep 2015, at 3:55 pm, Stephen Price <step...@perthprojects.com> wrote:
>> 
>> How did you get my Azure certificate? wtf??
>> 
>> Seriously though, the trailing == on the end (plus the overall look) makes
>> it look exactly like an Azure publish certificate.
>> 
>>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>>> 
>>> Perfect thanks Thomas.
>>> 
>>> I'll just have to add a base64 decode function and I should be fine.
>>> 
>>> Regards,
>>> 
>>> Greg
>>> 
>>> Dr Greg Low
>>> 
>>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913
>>> fax
>>> SQL Down Under | Web: www.sqldownunder.com
>>> 
>>> -Original Message-
>>> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
>>> On Behalf Of Thomas Koster
>>> Sent: Thursday, 10 September 2015 10:33 AM
>>> To: ozDotNet <ozdotnet@ozdotnet.com>
>>> Subject: Re: Odd text encoding
>>> 
>>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>>>> This one’s driving me crazy and I thought the brains trust might have
>>>> an idea.
>>>> 
>>>> Here’s a value that’s stored in an ntext column in a SQL Server DB:
>>>> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
>>>> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
>>>> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
>>>> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
>>>> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
>>>> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
>>>> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
>>>> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
>>>> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
>>>> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
>>>> x6lrjS6f1vK359184V9pkluuCgoAAA==
>>>> 
>>>> Somehow, that’s apparently meant to be either a) an XML file, or b) a
>>>> GZipped XML file.
>>> 
>>> echo "H4s" | base64 -d | gunzip
>>> 
>>> 

Re: Odd text encoding

[Nelson]

I cant understand why they don't just store the XML in the ntext column
directly in the first place...
maybe someone was hoping that gzip run can save some size?

Re Davy:
>> There are also performance implications with binary data,
I think its quite the contrary, there is an extra step involved going to &
from base64 and binary.

>> it's usually more secure to store as base64
oh god not again. base64 is just a representation of the data in printable
ASCII characters. -  think binary (base2), hex (base8) :)
base64 has absolutely nothing to do with security.

if security is what you are after, use proper encryption such as AES on the
original data, then base64 the output if you need to send/store as text



Nelson Chan

On 10 September 2015 at 19:50, Davy Jones <djones...@gmail.com> wrote:

> Probably because binary data was easy to put in and easy to get out, but
> what you put in is not what you get out.
> There are also performance implications with binary data, it's usually
> more secure to store as base64 in a varchar(max) or text.
> Absolutely no reason to store in an unicode column.
> Davy
>
> Sent from my iPhone
>
> > On 10 Sep 2015, at 09:47, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
> >
> > The data was stored by Biztalk, and of course it shoved binary data into
> an ntext data type column. The next two questions are:
> >
> > 1. Why put base 64 encoded data into an ntext (unicode) column when such
> a limited range of values can be generated?
> > 2. Why use a deprecated data type (ntext) in the first place?
> >
> > I'm sure that both questions are above my paygrade :-)
> >
> > Regards
> >
> > Greg
> >
> > Dr Greg Low
> > SQL Down Under
> > +61 419201410
> > 1300SQLSQL (1300775775)
> >
> >> On 10 Sep 2015, at 5:10 pm, Thomas Koster <tkos...@gmail.com> wrote:
> >>
> >> It is strange that base-64 encoding is even used here at all. Surely
> >> proper binary data types have been available in relational databases
> >> since the dark ages?
> >> --
> >> Thomas Koster
> >>
> >>
> >>> On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) <g...@greglow.com>
> wrote:
> >>> That was my first reaction too. Haven't spent time staring at base64
> >>> encoding for a long time. Knew someone would recognise it though. The
> brains
> >>> trust comes through again!
> >>>
> >>> Regards
> >>>
> >>> Greg
> >>>
> >>> Dr Greg Low
> >>> SQL Down Under
> >>> +61 419201410
> >>> 1300SQLSQL (1300775775)
> >>>
> >>> On 10 Sep 2015, at 3:55 pm, Stephen Price <step...@perthprojects.com>
> wrote:
> >>>
> >>> How did you get my Azure certificate? wtf??
> >>>
> >>> Seriously though, the trailing == on the end (plus the overall look)
> makes
> >>> it look exactly like an Azure publish certificate.
> >>>
> >>>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com>
> wrote:
> >>>>
> >>>> Perfect thanks Thomas.
> >>>>
> >>>> I'll just have to add a base64 decode function and I should be fine.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Greg
> >>>>
> >>>> Dr Greg Low
> >>>>
> >>>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676
> 4913
> >>>> fax
> >>>> SQL Down Under | Web: www.sqldownunder.com
> >>>>
> >>>> -Original Message-
> >>>> From: ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com]
> >>>> On Behalf Of Thomas Koster
> >>>> Sent: Thursday, 10 September 2015 10:33 AM
> >>>> To: ozDotNet <ozdotnet@ozdotnet.com>
> >>>> Subject: Re: Odd text encoding
> >>>>
> >>>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com>
> wrote:
> >>>>> This one’s driving me crazy and I thought the brains trust might have
> >>>>> an idea.
> >>>>>
> >>>>> Here’s a value that’s stored in an ntext column in a SQL Server DB:
> >>>>>
> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
> >>>>>
> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
> >>>>>
> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
> >>>>>
> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
> >>>>>
> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
> >>>>>
> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
> >>>>>
> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
> >>>>>
> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
> >>>>>
> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
> >>>>>
> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
> >>>>> x6lrjS6f1vK359184V9pkluuCgoAAA==
> >>>>>
> >>>>> Somehow, that’s apparently meant to be either a) an XML file, or b) a
> >>>>> GZipped XML file.
> >>>>
> >>>> echo "H4s" | base64 -d | gunzip
> >>>>
> >>>> 
>

Re: Odd text encoding

[David Rhys Jones]

I cant understand why they don't just store the XML in the ntext column
directly in the first place...
maybe someone was hoping that gzip run can save some size?

Re Davy:
>> There are also performance implications with binary data,
>I think its quite the contrary, there is an extra step involved going to &
from base64 and binary.

Database performance, high critical databases it's faster to write text
than binary, this might have changed with the last version of SQL but it
was true up until '2008

>> it's usually more secure to store as base64
>oh god not again. base64 is just a representation of the data in printable
ASCII characters. -  think binary (base2), hex (base8) :)
>base64 has absolutely nothing to do with security.

>if security is what you are after, use proper encryption such as AES on
the original data, then base64 the output if you need >to send/store as text

Completely missed my point, I'm not talking about encryption at all,  it's
more secure to store as base64, as you don't get problems trying to get the
data back out. Just that what you put in is what you are getting out,
without strange driver problems or Collation issues.

Davy.




*Si hoc legere scis nimium eruditionis habes*.


On Thu, Sep 10, 2015 at 12:00 PM, Nelson <nelson.honey...@gmail.com> wrote:

> I cant understand why they don't just store the XML in the ntext column
> directly in the first place...
> maybe someone was hoping that gzip run can save some size?
>
> Re Davy:
> >> There are also performance implications with binary data,
> I think its quite the contrary, there is an extra step involved going to &
> from base64 and binary.
>
> >> it's usually more secure to store as base64
> oh god not again. base64 is just a representation of the data in printable
> ASCII characters. -  think binary (base2), hex (base8) :)
> base64 has absolutely nothing to do with security.
>
> if security is what you are after, use proper encryption such as AES on
> the original data, then base64 the output if you need to send/store as text
>
>
>
> Nelson Chan
>
> On 10 September 2015 at 19:50, Davy Jones <djones...@gmail.com> wrote:
>
>> Probably because binary data was easy to put in and easy to get out, but
>> what you put in is not what you get out.
>> There are also performance implications with binary data, it's usually
>> more secure to store as base64 in a varchar(max) or text.
>> Absolutely no reason to store in an unicode column.
>> Davy
>>
>> Sent from my iPhone
>>
>> > On 10 Sep 2015, at 09:47, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>> >
>> > The data was stored by Biztalk, and of course it shoved binary data
>> into an ntext data type column. The next two questions are:
>> >
>> > 1. Why put base 64 encoded data into an ntext (unicode) column when
>> such a limited range of values can be generated?
>> > 2. Why use a deprecated data type (ntext) in the first place?
>> >
>> > I'm sure that both questions are above my paygrade :-)
>> >
>> > Regards
>> >
>> > Greg
>> >
>> > Dr Greg Low
>> > SQL Down Under
>> > +61 419201410
>> > 1300SQLSQL (1300775775)
>> >
>> >> On 10 Sep 2015, at 5:10 pm, Thomas Koster <tkos...@gmail.com> wrote:
>> >>
>> >> It is strange that base-64 encoding is even used here at all. Surely
>> >> proper binary data types have been available in relational databases
>> >> since the dark ages?
>> >> --
>> >> Thomas Koster
>> >>
>> >>
>> >>> On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) <g...@greglow.com>
>> wrote:
>> >>> That was my first reaction too. Haven't spent time staring at base64
>> >>> encoding for a long time. Knew someone would recognise it though. The
>> brains
>> >>> trust comes through again!
>> >>>
>> >>> Regards
>> >>>
>> >>> Greg
>> >>>
>> >>> Dr Greg Low
>> >>> SQL Down Under
>> >>> +61 419201410
>> >>> 1300SQLSQL (1300775775)
>> >>>
>> >>> On 10 Sep 2015, at 3:55 pm, Stephen Price <step...@perthprojects.com>
>> wrote:
>> >>>
>> >>> How did you get my Azure certificate? wtf??
>> >>>
>> >>> Seriously though, the trailing == on the end (plus the overall look)
>> makes
>> >>> it look exactly like an Azure publish certificate.
>> >>>
>> >>>> On Thu, 10 Sep 2015 a

Re: Odd text encoding

[Greg Keogh]

>
> i think ive read it somewhere, a rule of thumb is if you dont need to do
> calculations with your "number", make it a string
>
In 2006 where I was working they created a new SQL DB and the natural key
of the most important table was a 12 digit number (customer number I think)
and there were arguments about if the PK should be a string or a number.
For some reason they chose a DECIMAL(12,0) which vaguely worried me, but I
didn't get involved and I still wonder if a 64-bit integer would have been
better, or even a CHAR(12) ... still dunno.

*GK*

Re: Odd text encoding

[Nelson]

Yea the phone number thing *facepalm*
ask them how they gonna store 000 as number.

i think ive read it somewhere, a rule of thumb is if you dont need to do
calculations with your "number", make it a string
On 10 Sep 2015 21:13, "DotNet Dude" <adotnetd...@gmail.com> wrote:

> >From my experience there usually is no good reason for this sort of
> thing. I've seen people attempt to store phone numbers as a number and
> surely most here have seen similar things.
>
> On Thursday, 10 September 2015, Greg Low (罗格雷格博士) <g...@greglow.com>
> wrote:
>
>> The data was stored by Biztalk, and of course it shoved binary data into
>> an ntext data type column. The next two questions are:
>>
>> 1. Why put base 64 encoded data into an ntext (unicode) column when such
>> a limited range of values can be generated?
>> 2. Why use a deprecated data type (ntext) in the first place?
>>
>> I'm sure that both questions are above my paygrade :-)
>>
>> Regards
>>
>> Greg
>>
>> Dr Greg Low
>> SQL Down Under
>> +61 419201410
>> 1300SQLSQL (1300775775)
>>
>> > On 10 Sep 2015, at 5:10 pm, Thomas Koster <tkos...@gmail.com> wrote:
>> >
>> > It is strange that base-64 encoding is even used here at all. Surely
>> > proper binary data types have been available in relational databases
>> > since the dark ages?
>> > --
>> > Thomas Koster
>> >
>> >
>> >> On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) <g...@greglow.com>
>> wrote:
>> >> That was my first reaction too. Haven't spent time staring at base64
>> >> encoding for a long time. Knew someone would recognise it though. The
>> brains
>> >> trust comes through again!
>> >>
>> >> Regards
>> >>
>> >> Greg
>> >>
>> >> Dr Greg Low
>> >> SQL Down Under
>> >> +61 419201410
>> >> 1300SQLSQL (1300775775)
>> >>
>> >> On 10 Sep 2015, at 3:55 pm, Stephen Price <step...@perthprojects.com>
>> wrote:
>> >>
>> >> How did you get my Azure certificate? wtf??
>> >>
>> >> Seriously though, the trailing == on the end (plus the overall look)
>> makes
>> >> it look exactly like an Azure publish certificate.
>> >>
>> >>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com>
>> wrote:
>> >>>
>> >>> Perfect thanks Thomas.
>> >>>
>> >>> I'll just have to add a base64 decode function and I should be fine.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Greg
>> >>>
>> >>> Dr Greg Low
>> >>>
>> >>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676
>> 4913
>> >>> fax
>> >>> SQL Down Under | Web: www.sqldownunder.com
>> >>>
>> >>> -Original Message-
>> >>> From: ozdotnet-boun...@ozdotnet.com [mailto:
>> ozdotnet-boun...@ozdotnet.com]
>> >>> On Behalf Of Thomas Koster
>> >>> Sent: Thursday, 10 September 2015 10:33 AM
>> >>> To: ozDotNet <ozdotnet@ozdotnet.com>
>> >>> Subject: Re: Odd text encoding
>> >>>
>> >>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com>
>> wrote:
>> >>>> This one’s driving me crazy and I thought the brains trust might have
>> >>>> an idea.
>> >>>>
>> >>>> Here’s a value that’s stored in an ntext column in a SQL Server DB:
>> >>>>
>> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
>> >>>>
>> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
>> >>>>
>> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
>> >>>>
>> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
>> >>>>
>> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
>> >>>>
>> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
>> >>>>
>> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
>> >>>>
>> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
>> >>>>
>> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
>> >>>>
>> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
>> >>>> x6lrjS6f1vK359184V9pkluuCgoAAA==
>> >>>>
>> >>>> Somehow, that’s apparently meant to be either a) an XML file, or b) a
>> >>>> GZipped XML file.
>> >>>
>> >>> echo "H4s" | base64 -d | gunzip
>> >>>
>> >>> 
>>
>

Re: Odd text encoding

[DotNet Dude]

>From my experience there usually is no good reason for this sort of thing.
I've seen people attempt to store phone numbers as a number and surely most
here have seen similar things.

On Thursday, 10 September 2015, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:

> The data was stored by Biztalk, and of course it shoved binary data into
> an ntext data type column. The next two questions are:
>
> 1. Why put base 64 encoded data into an ntext (unicode) column when such a
> limited range of values can be generated?
> 2. Why use a deprecated data type (ntext) in the first place?
>
> I'm sure that both questions are above my paygrade :-)
>
> Regards
>
> Greg
>
> Dr Greg Low
> SQL Down Under
> +61 419201410
> 1300SQLSQL (1300775775)
>
> > On 10 Sep 2015, at 5:10 pm, Thomas Koster <tkos...@gmail.com
> <javascript:;>> wrote:
> >
> > It is strange that base-64 encoding is even used here at all. Surely
> > proper binary data types have been available in relational databases
> > since the dark ages?
> > --
> > Thomas Koster
> >
> >
> >> On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) <g...@greglow.com
> <javascript:;>> wrote:
> >> That was my first reaction too. Haven't spent time staring at base64
> >> encoding for a long time. Knew someone would recognise it though. The
> brains
> >> trust comes through again!
> >>
> >> Regards
> >>
> >> Greg
> >>
> >> Dr Greg Low
> >> SQL Down Under
> >> +61 419201410
> >> 1300SQLSQL (1300775775)
> >>
> >> On 10 Sep 2015, at 3:55 pm, Stephen Price <step...@perthprojects.com
> <javascript:;>> wrote:
> >>
> >> How did you get my Azure certificate? wtf??
> >>
> >> Seriously though, the trailing == on the end (plus the overall look)
> makes
> >> it look exactly like an Azure publish certificate.
> >>
> >>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com
> <javascript:;>> wrote:
> >>>
> >>> Perfect thanks Thomas.
> >>>
> >>> I'll just have to add a base64 decode function and I should be fine.
> >>>
> >>> Regards,
> >>>
> >>> Greg
> >>>
> >>> Dr Greg Low
> >>>
> >>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676
> 4913
> >>> fax
> >>> SQL Down Under | Web: www.sqldownunder.com
> >>>
> >>> -Original Message-
> >>> From: ozdotnet-boun...@ozdotnet.com <javascript:;> [mailto:
> ozdotnet-boun...@ozdotnet.com <javascript:;>]
> >>> On Behalf Of Thomas Koster
> >>> Sent: Thursday, 10 September 2015 10:33 AM
> >>> To: ozDotNet <ozdotnet@ozdotnet.com <javascript:;>>
> >>> Subject: Re: Odd text encoding
> >>>
> >>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com
> <javascript:;>> wrote:
> >>>> This one’s driving me crazy and I thought the brains trust might have
> >>>> an idea.
> >>>>
> >>>> Here’s a value that’s stored in an ntext column in a SQL Server DB:
> >>>> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
> >>>> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
> >>>> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
> >>>> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
> >>>> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
> >>>> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
> >>>> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
> >>>> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
> >>>> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
> >>>> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
> >>>> x6lrjS6f1vK359184V9pkluuCgoAAA==
> >>>>
> >>>> Somehow, that’s apparently meant to be either a) an XML file, or b) a
> >>>> GZipped XML file.
> >>>
> >>> echo "H4s" | base64 -d | gunzip
> >>>
> >>> 
>

Re: Odd text encoding

[Greg Harris]

Oh Yeah!

Friday rant to follow...

>From my experience there usually is no good reason for this sort of thing.
I've seen people attempt to store phone numbers as a number and surely most
here have seen similar things.
>Yea the phone number thing *facepalm*
>ask them how they gonna store 000 as number.
>i think ive read it somewhere, a rule of thumb is if you dont need to do
calculations with your "number", make it a string

Several years ago we were working on a soft copy bill delivery system for
one of the telcos.
The specification I wrote said that the phone number was a text field with
a maximum length of some large number.

The vendor who wrote the analysis software for us saw NUMBER looked at a
few of them and said IT MUST BE AN INTEGER!
and besides integers are small and fast to process => good.
When you dialled special numbers, text would be put in the field, like
"000" became "Emergency Services"
Or for an international number the international prefix would be replaced
by a "+".
They got very upset when they ran through the bulk of the test data we gave
them with the specification and many of them failed!

Yes I think that I agree with the comment "a rule of thumb is if you don't
need to do calculations with your "number", make it a string"

I may reword that as if the number is a measurement, it probably is best
being a numeric, if it is a business generated identification it is
probably best being a string.

Have fun

Greg #27

Re: Odd text encoding

[Thomas Koster]

On 10 September 2015 at 22:09, David Rhys Jones  wrote:
> Database performance, high critical databases it's faster to write text than
> binary, this might have changed with the last version of SQL but it was true
> up until '2008

Binary data is naturally faster to copy and compare than text because
processing text must always consider encodings and collations, and
sometimes line endings too, whereas binary data is copied with memcpy
and compared with memcmp.

If binary values are slower in a particular DBMS, then that
implementation has added some artificial costs to using binary data
(for example, by allowing varchar but not varbinary to be stored
directly in the leaves of the b-tree).

Base-64-encoding a value also increases its storage size by 33%. That is
a significant overhead that reaches beyond the DBMS, with equally
significant potential to affect many performance metrics (e.g. more CPU
cache misses, more OS buffer cache misses, more page faults, more I/O
everywhere, higher infrastructure costs).

> it's more secure to store as base64, as you don't get problems trying to get
> the data back out. Just that what you put in is what you are getting out,
> without strange driver problems or Collation issues.

Base-64-encoded values are *text*. If you store base-64-encoded values
inside a database, you are actually introducing an additional risk of
text-encoding and collation problems when there previously was none.

In my view, there is never a good reason to store base-64-encoded values
in a database system that has a varbinary (or equivalent) data type.

--
Thomas Koster

RE: Odd text encoding

[罗格雷格博士]

The thing to understand with databases like SQL Server is that as soon as you 
start comparing and/or joining values, you really hope that they are integers 
(or bigints). If I had a 12 digit number that was a customer number, I’d just 
be using a bigint.

As soon as you start comparing character values, things get slow. It might seem 
simple to write a statement like

WHERE Somecolumn = ‘A’

But unfortunately, that’s not a simple comparison. SQL Server has to apply all 
the rules for the specified collation, and then do that column by column. It’s 
a relatively big job, certainly nothing like “are these two integers the same 
value?”.

I was at a site recently where they were changing all the IDs from bigint to 
uniqueidentifier (GUID), not for any real GUID-related reason, but because they 
were concerned about the possibility of running out of bigint values. (Clearly 
it’s a pity more maths isn’t taught at schools).

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/>

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Thursday, 10 September 2015 10:12 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Odd text encoding


i think ive read it somewhere, a rule of thumb is if you dont need to do 
calculations with your "number", make it a string
In 2006 where I was working they created a new SQL DB and the natural key of 
the most important table was a 12 digit number (customer number I think) and 
there were arguments about if the PK should be a string or a number. For some 
reason they chose a DECIMAL(12,0) which vaguely worried me, but I didn't get 
involved and I still wonder if a 64-bit integer would have been better, or even 
a CHAR(12) ... still dunno.

GK

Re: Odd text encoding

[罗格雷格博士]

es
>>> it look exactly like an Azure publish certificate.
>>>
>>>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) 
>>>> <g...@greglow.com<mailto:g...@greglow.com>> wrote:
>>>>
>>>> Perfect thanks Thomas.
>>>>
>>>> I'll just have to add a base64 decode function and I should be fine.
>>>>
>>>> Regards,
>>>>
>>>> Greg
>>>>
>>>> Dr Greg Low
>>>>
>>>> 1300SQLSQL (1300 775 775) office | +61 419201410<tel:%2B61%20419201410> 
>>>> mobile│ +61 3 8676 4913<tel:%2B61%203%208676%204913>
>>>> fax
>>>> SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com>
>>>>
>>>> -Original Message-
>>>> From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
>>>> [mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>]
>>>> On Behalf Of Thomas Koster
>>>> Sent: Thursday, 10 September 2015 10:33 AM
>>>> To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
>>>> Subject: Re: Odd text encoding
>>>>
>>>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
>>>>> <g...@greglow.com<mailto:g...@greglow.com>> wrote:
>>>>> This one’s driving me crazy and I thought the brains trust might have
>>>>> an idea.
>>>>>
>>>>> Here’s a value that’s stored in an ntext column in a SQL Server DB:
>>>>> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
>>>>> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
>>>>> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
>>>>> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
>>>>> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
>>>>> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
>>>>> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
>>>>> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
>>>>> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
>>>>> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
>>>>> x6lrjS6f1vK359184V9pkluuCgoAAA==
>>>>>
>>>>> Somehow, that’s apparently meant to be either a) an XML file, or b) a
>>>>> GZipped XML file.
>>>>
>>>> echo "H4s" | base64 -d | gunzip
>>>>
>>>> 

RE: Odd text encoding

[罗格雷格博士]

How long would it take to insert that many rows? ☺

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/>

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Friday, 11 September 2015 10:15 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Odd text encoding

but because they were concerned about the possibility of running out of bigint 
values. (Clearly it’s a pity more maths isn’t taught at schools).

My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63 
non-stop it will take 5444 years -- GK

Re: Odd text encoding

[Greg Keogh]

>
> but because they were concerned about the possibility of running out of
> bigint values. (Clearly it’s a pity more maths isn’t taught at schools).
>

My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63
non-stop it will take 5444 years -- *GK*

RE: Odd text encoding

[Ken Schaefer]

Security is more than just permitting/denying access. Security is also about 
maintaining your data’s integrity/fidelity. I think that’s what Davy was 
alluding to.


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Nelson
Sent: Thursday, 10 September 2015 8:00 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Odd text encoding


>> it's usually more secure to store as base64
oh god not again. base64 is just a representation of the data in printable 
ASCII characters. -  think binary (base2), hex (base8) :)
base64 has absolutely nothing to do with security.

if security is what you are after, use proper encryption such as AES on the 
original data, then base64 the output if you need to send/store as text



Nelson Chan

On 10 September 2015 at 19:50, Davy Jones 
<djones...@gmail.com<mailto:djones...@gmail.com>> wrote:
Probably because binary data was easy to put in and easy to get out, but what 
you put in is not what you get out.
There are also performance implications with binary data, it's usually more 
secure to store as base64 in a varchar(max) or text.
Absolutely no reason to store in an unicode column.
Davy

Sent from my iPhone

> On 10 Sep 2015, at 09:47, Greg Low (罗格雷格博士) 
> <g...@greglow.com<mailto:g...@greglow.com>> wrote:
>
> The data was stored by Biztalk, and of course it shoved binary data into an 
> ntext data type column. The next two questions are:
>
> 1. Why put base 64 encoded data into an ntext (unicode) column when such a 
> limited range of values can be generated?
> 2. Why use a deprecated data type (ntext) in the first place?
>
> I'm sure that both questions are above my paygrade :-)
>
> Regards
>
> Greg
>
> Dr Greg Low
> SQL Down Under
> +61 419201410<tel:%2B61%20419201410>
> 1300SQLSQL (1300775775)
>
>> On 10 Sep 2015, at 5:10 pm, Thomas Koster 
>> <tkos...@gmail.com<mailto:tkos...@gmail.com>> wrote:
>>
>> It is strange that base-64 encoding is even used here at all. Surely
>> proper binary data types have been available in relational databases
>> since the dark ages?
>> --
>> Thomas Koster
>>
>>
>>> On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) 
>>> <g...@greglow.com<mailto:g...@greglow.com>> wrote:
>>> That was my first reaction too. Haven't spent time staring at base64
>>> encoding for a long time. Knew someone would recognise it though. The brains
>>> trust comes through again!
>>>
>>> Regards
>>>
>>> Greg
>>>
>>> Dr Greg Low
>>> SQL Down Under
>>> +61 419201410<tel:%2B61%20419201410>
>>> 1300SQLSQL (1300775775)
>>>
>>> On 10 Sep 2015, at 3:55 pm, Stephen Price 
>>> <step...@perthprojects.com<mailto:step...@perthprojects.com>> wrote:
>>>
>>> How did you get my Azure certificate? wtf??
>>>
>>> Seriously though, the trailing == on the end (plus the overall look) makes
>>> it look exactly like an Azure publish certificate.
>>>
>>>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) 
>>>> <g...@greglow.com<mailto:g...@greglow.com>> wrote:
>>>>
>>>> Perfect thanks Thomas.
>>>>
>>>> I'll just have to add a base64 decode function and I should be fine.
>>>>
>>>> Regards,
>>>>
>>>> Greg
>>>>
>>>> Dr Greg Low
>>>>
>>>> 1300SQLSQL (1300 775 775) office | +61 419201410<tel:%2B61%20419201410> 
>>>> mobile│ +61 3 8676 4913<tel:%2B61%203%208676%204913>
>>>> fax
>>>> SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com>
>>>>
>>>> -Original Message-
>>>> From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
>>>> [mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>]
>>>> On Behalf Of Thomas Koster
>>>> Sent: Thursday, 10 September 2015 10:33 AM
>>>> To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
>>>> Subject: Re: Odd text encoding
>>>>
>>>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
>>>>> <g...@greglow.com<mailto:g...@greglow.com>> wrote:
>>>>> This one’s driving me crazy and I thought the brains trust might have
>>>>> an idea.
>>>>>
>>>>> Here’s a value that’s stored in an ntext column in a SQL Server DB:
>>>>> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
>>>>> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
>>>>> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
>>>>> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
>>>>> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
>>>>> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
>>>>> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
>>>>> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
>>>>> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
>>>>> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
>>>>> x6lrjS6f1vK359184V9pkluuCgoAAA==
>>>>>
>>>>> Somehow, that’s apparently meant to be either a) an XML file, or b) a
>>>>> GZipped XML file.
>>>>
>>>> echo "H4s" | base64 -d | gunzip
>>>>
>>>> 

RE: Odd text encoding

[Ken Schaefer]

And what would those numbers have looked like 2 years ago? 4 years ago? 10 
years ago?

Assuming computing power doubles every 18-24 months, then that 5444 years will 
become a lot less, relatively quickly.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Friday, 11 September 2015 10:15 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Odd text encoding

but because they were concerned about the possibility of running out of bigint 
values. (Clearly it’s a pity more maths isn’t taught at schools).

My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63 
non-stop it will take 5444 years -- GK

Re: Odd text encoding

[Nelson]

Stephen,

That base64 encoding - see https://en.wikipedia.org/wiki/Base64
the == at the end is for padding.


base64 is a common way to encode binary data in plaintext string (gzip in
this our case here)


Regards,

Nelson Chan

On 10 September 2015 at 15:55, Stephen Price <step...@perthprojects.com>
wrote:

> How did you get my Azure certificate? wtf??
>
> Seriously though, the trailing == on the end (plus the overall look) makes
> it look exactly like an Azure publish certificate.
>
> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>
>> Perfect thanks Thomas.
>>
>> I'll just have to add a base64 decode function and I should be fine.
>>
>> Regards,
>>
>> Greg
>>
>> Dr Greg Low
>>
>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913
>> fax
>> SQL Down Under | Web: www.sqldownunder.com
>>
>> -Original Message-
>> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
>> On Behalf Of Thomas Koster
>> Sent: Thursday, 10 September 2015 10:33 AM
>> To: ozDotNet <ozdotnet@ozdotnet.com>
>> Subject: Re: Odd text encoding
>>
>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com>
>> wrote:
>> > This one’s driving me crazy and I thought the brains trust might have
>> > an idea.
>> >
>> > Here’s a value that’s stored in an ntext column in a SQL Server DB:
>> > H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
>> > GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
>> > RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
>> > S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
>> > vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
>> > zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
>> > txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
>> > vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
>> > 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
>> > 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
>> > x6lrjS6f1vK359184V9pkluuCgoAAA==
>> >
>> > Somehow, that’s apparently meant to be either a) an XML file, or b) a
>> > GZipped XML file.
>>
>> echo "H4s" | base64 -d | gunzip
>>
>> 
>>
>

Re: Odd text encoding

[罗格雷格博士]

That was my first reaction too. Haven't spent time staring at base64 encoding 
for a long time. Knew someone would recognise it though. The brains trust comes 
through again!

Regards

Greg

Dr Greg Low
SQL Down Under
+61 419201410
1300SQLSQL (1300775775)

On 10 Sep 2015, at 3:55 pm, Stephen Price 
<step...@perthprojects.com<mailto:step...@perthprojects.com>> wrote:

How did you get my Azure certificate? wtf??

Seriously though, the trailing == on the end (plus the overall look) makes it 
look exactly like an Azure publish certificate.

On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) 
<g...@greglow.com<mailto:g...@greglow.com>> wrote:
Perfect thanks Thomas.

I'll just have to add a base64 decode function and I should be fine.

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com>

-Original Message-
From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Thomas Koster
Sent: Thursday, 10 September 2015 10:33 AM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Odd text encoding

On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
<g...@greglow.com<mailto:g...@greglow.com>> wrote:
> This one’s driving me crazy and I thought the brains trust might have
> an idea.
>
> Here’s a value that’s stored in an ntext column in a SQL Server DB:
> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
> x6lrjS6f1vK359184V9pkluuCgoAAA==
>
> Somehow, that’s apparently meant to be either a) an XML file, or b) a
> GZipped XML file.

echo "H4s" | base64 -d | gunzip

Odd text encoding

[罗格雷格博士]

Hi Folks,

This one’s driving me crazy and I thought the brains trust might have an idea.

Here’s a value that’s stored in an ntext column in a SQL Server DB:

H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33SfmGGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99tRCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQIS8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFavuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCwzxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CBtxDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVzx6lrjS6f1vK359184V9pkluuCgoAAA==

Somehow, that’s apparently meant to be either a) an XML file, or b) a GZipped 
XML file.

Anyone recognise the format?

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com

RE: Odd text encoding

[罗格雷格博士]

The tail end of it looks a bit like values that I see in certificates.

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/>

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low (??)
Sent: Thursday, 10 September 2015 10:21 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Odd text encoding

Hi Folks,

This one’s driving me crazy and I thought the brains trust might have an idea.

Here’s a value that’s stored in an ntext column in a SQL Server DB:

H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33SfmGGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99tRCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQIS8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFavuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCwzxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CBtxDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVzx6lrjS6f1vK359184V9pkluuCgoAAA==

Somehow, that’s apparently meant to be either a) an XML file, or b) a GZipped 
XML file.

Anyone recognise the format?

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/>

Re: Odd text encoding

[Thomas Koster]

On 10 September 2015 at 10:21, Greg Low (罗格雷格博士)  wrote:
> This one’s driving me crazy and I thought the brains trust might have an
> idea.
>
> Here’s a value that’s stored in an ntext column in a SQL Server DB:
> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33SfmGGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99tRCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQIS8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFavuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCwzxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CBtxDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVzx6lrjS6f1vK359184V9pkluuCgoAAA==
>
> Somehow, that’s apparently meant to be either a) an XML file, or b) a
> GZipped XML file.

echo "H4s" | base64 -d | gunzip

http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo;
xmlns:ns11="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveMemberVideoLink;
xmlns:ns8="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveMemberPersonalDetails;
xmlns:ns4="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveMemberAccountIdentification;
xmlns:ns5="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveMemberAccountSummary;
xmlns:ns9="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveMemberSuperInvestmentOptions;
xmlns:ns14="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveSuperAccountTransactionHistory;
xmlns:ns7="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveMemberContactDetails;
xmlns:ns17="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/UpdateAddressDetails;
xmlns:ns16="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/sp_get_pension_account_balance2;
xmlns:ns21="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/UpdatePhoneDetails;
xmlns:ns1="http://schemas.microsoft.com/2003/10/Serialization/;
xmlns:ns19="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/UpdateMemberPassword;
xmlns:ns3="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveAccountSpecialConditions;
xmlns:ns10="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveMemberTaxationDetails;
xmlns:ns6="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveMemberBasicDetails;
xmlns:ns13="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrievePensionAccountTransactionHistory;
xmlns:ns20="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/UpdateMemberPersonalDetails;
xmlns:ns15="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/RetrieveUsernamePassword;
xmlns:ns18="http://schemas.microsoft.com/Sql/2008/05/ProceduresResultSets/dbo/UpdateEmailDetails;>301737ACCUM1CONTRIBUTION2015-07-012015-08-07100301737

--
Thomas Koster

RE: Odd text encoding

[罗格雷格博士]

Perfect thanks Thomas.

I'll just have to add a base64 decode function and I should be fine.

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax 
SQL Down Under | Web: www.sqldownunder.com

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Thomas Koster
Sent: Thursday, 10 September 2015 10:33 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Odd text encoding

On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
> This one’s driving me crazy and I thought the brains trust might have 
> an idea.
>
> Here’s a value that’s stored in an ntext column in a SQL Server DB:
> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
> x6lrjS6f1vK359184V9pkluuCgoAAA==
>
> Somehow, that’s apparently meant to be either a) an XML file, or b) a 
> GZipped XML file.

echo "H4s" | base64 -d | gunzip

Re: Odd text encoding

[Stephen Price]

How did you get my Azure certificate? wtf??

Seriously though, the trailing == on the end (plus the overall look) makes
it look exactly like an Azure publish certificate.

On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com> wrote:

> Perfect thanks Thomas.
>
> I'll just have to add a base64 decode function and I should be fine.
>
> Regards,
>
> Greg
>
> Dr Greg Low
>
> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913
> fax
> SQL Down Under | Web: www.sqldownunder.com
>
> -Original Message-
> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
> On Behalf Of Thomas Koster
> Sent: Thursday, 10 September 2015 10:33 AM
> To: ozDotNet <ozdotnet@ozdotnet.com>
> Subject: Re: Odd text encoding
>
> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
> > This one’s driving me crazy and I thought the brains trust might have
> > an idea.
> >
> > Here’s a value that’s stored in an ntext column in a SQL Server DB:
> > H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm
> > GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t
> > RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI
> > S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa
> > vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw
> > zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB
> > txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3
> > vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol
> > 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg
> > 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz
> > x6lrjS6f1vK359184V9pkluuCgoAAA==
> >
> > Somehow, that’s apparently meant to be either a) an XML file, or b) a
> > GZipped XML file.
>
> echo "H4s" | base64 -d | gunzip
>
> 
>