Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

gzip 2

Status
Not open for further replies.

tedsmith

Programmer
Nov 23, 2000
1,762
AU
I am looking at receiving a gzipped CSV data from the internet.
WinHTTP doesnt seem to unzip files whereas WINinet does.
Is there a way of using the data received by WinHTTP and separately unzipping the text data in vb6?
It is not an actual file at any stage, just data.
 
The server should never be using GZIP or deflate compression unless you have added an Accept-Encoding header specifying one or both. It it does, it's a broken server.

However in order to deal with that you would have to use a 3rd party library such as zlibwapi, which is a StdCall-compiled version of zlib with some extra zlib stuff in it.

Look at the first answer under How can I decompress a gzip stream with zlib?
 
Thanks,
The client has decided not to compress it but may in the future.
This 'server' is dedicated just for this use so maybe it doesn't matter whether is 'broken' or not
 
Well "broken" is in the eye of the beholder after all. Those RFCs can sometimes be interpreted different ways.

I think I have GZip-format deflate and inflate working using zlibwapi but it was a little tricky. It turns out that zlibwapi has changed a few function signatures for some reason, and it doesn't seem to be documented anywhere. I found some awkward VB6 code that only inflates but that gave me enough clues to start experimenting.

My code works with itself, but I need to verify it against existing servers and clients.


Here are those functions that are altered:

Code:
'This zlibwapi function signature varies from the standard zlib function
'for some strange reason, and it does not seem to be documented anywhere.
'It has two additional parameters:
Private Declare Function deflateInit2_ Lib "zlibwapi" ( _
    ByRef strm As z_stream, _
    ByVal level As Long, _
    ByVal method As Long, _
    ByVal windowBits As Long, _
    ByVal memLevel As Long, _
    ByVal strategy As Long, _
    ByVal pszZLibVersion As Long, _
    ByVal cbStrm As Long) As Long

'This zlibwapi function signature varies from the standard zlib function
'for some strange reason, and it does not seem to be documented anywhere.
'It has two additional parameters:
Private Declare Function inflateInit2_ Lib "zlibwapi" ( _
    ByRef strm As z_stream, _
    ByVal windowBits As Long, _
    ByVal pszZLibVersion As Long, _
    ByVal cbStrm As Long) As Long
 
Yep, using zlibwapi.dll for gzip compression works fine. Tested with IE 9 and Maxthon 3.3.9 Portable browsers (the only ones handy) and it works with them so I'd trust it.

Just not for deflate compression due to long-standing problems with how Microsoft HTTP clients have incorrectly implemented it. This is why almost nobody's servers support deflate anymore.
 

concerning the decimal separators, the Cap project doesn't seem to be local aware
 
concerning the decimal separators, the Cap project doesn't seem to be local aware

Cab project?

I'm not sure where locale settings become an issue there. There isn't any data display or entry involved. And the data passed from Cab to CabTrack takes place in ADO's binary ADTG or textual XML formats, neither of which are locale-specific.

In XML data true is always "true" and numeric values always use "." as decimal point, etc. You only see exceptions in "pidgeon XML" people whang together while ignoring the rules.

Or is there a locale issue somewhere else I missed? If so perhaps you can correct it if it offends your sensibilities. [wink]

Can you spell "demo?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top