• 0

[C# Help] PHP Compatible String GZip


Question

Firstly I'm not a real application developer, I primarily work on the web-side of things and most of the issues I'm dealing with are things I've never looked at before so I'm at a loss as to a solution for my current problem.

But I'm currently working on a small desktop application that periodically uploads a string to a website every 20-30 seconds, to reduce the time it takes and to reduce any latency issues I'm looking to gzip the string before sending it to a php script. I've gotten a few examples of the compression function on the C# side of things and plenty examples of gzip (de)compression in PHP, but after hours of looking I haven't found a way to get it to work with PHPs gzinflate(), gzdecode() or gzuncompress(). I was wondering if anyone has managed to get this type of marriage to work before?

The current c# compression function I'm using:

        public static string Compress(string text)
        {

            byte[] buffer = Encoding.UTF8.GetBytes(text);
            MemoryStream ms = new MemoryStream();
            using (GZipStream zip = new GZipStream(ms, CompressionMode.Compress, true))
            {
                zip.Write(buffer, 0, buffer.Length);
            }

            ms.Position = 0;
            MemoryStream outStream = new MemoryStream();

            byte[] compressed = new byte[ms.Length];
            ms.Read(compressed, 0, compressed.Length);

            byte[] gzBuffer = new byte[compressed.Length + 4];
            System.Buffer.BlockCopy(compressed, 0, gzBuffer, 4, compressed.Length);
            System.Buffer.BlockCopy(BitConverter.GetBytes(buffer.Length), 0, gzBuffer, 0, 4);

            return Convert.ToBase64String(gzBuffer);
        }

Example output from the function that is sent to the PHP script via post: http://www.recount.me/gzip.txt

Which I am then trying to use any of the following functions to decode:

	echo gzinflate(base64_decode($str));
	echo '<br /><br />';
	echo gzdecode(base64_decode($str));
	echo '<br /><br />';
	echo gzuncompress(base64_decode($str));

After looking around I think the issue lies with the fact that many of the PHP functions are designed with files and because I'm using a string it has no header/footer data that it expects to see, but having never really worked with c# or gzip I have no idea how to fix the problem and any advice/help would be very much appreciated.

Thanks for reading.

Link to comment
https://www.neowin.net/forum/topic/994146-c-help-php-compatible-string-gzip/
Share on other sites

2 answers to this question

Recommended Posts

  • 0

Well, that block of C# code adds a 4-byte length to the beginning of the gzip-encoded data, which by definition includes a header and a CRC/length trailer. So of course the PHP functions won't recognize it. Cut out all of that BlockCopy crap.

Not tested, but maybe something like this:

public static string Compress(string text)
{
    byte[] buffer = Encoding.UTF8.GetBytes(text);
    string output = String.Empty;

    using (MemoryStream ms = new MemoryStream())
    {
        using (GZipStream zip = new GZipStream(ms, CompressionMode.Compress, true)
        {
            zip.Write(buffer, 0, buffer.Length);
        }

        output = Convert.ToBase64String(ms.ToArray());
    }

    return output;
}

  • 0

Thank you so much for the quick reply and even more so for a working solution...I can't believe it was that simple in the end!

I ripped out the useless parts like you suggested rather than using your code and it work perfectly. So the final solution I'm using is:

        public static string Compress(string text)
        {

            byte[] buffer = Encoding.UTF8.GetBytes(text);

            var memoryStream = new MemoryStream();
            using (var gZipStream = new GZipStream(memoryStream, CompressionMode.Compress, true))
            {
                gZipStream.Write(buffer, 0, buffer.Length);
            }

            memoryStream.Position = 0;

            var compressedData = new byte[memoryStream.Length];
            memoryStream.Read(compressedData, 0, compressedData.Length);

            return Convert.ToBase64String(compressedData);
        }

And for the php side:

<?php

	$str = trim($_REQUEST['data']);
	echo gzdecode(base64_decode($str));

?>

And it's taking 70KB strings down to 10KB without any loss of data which is exactly what I was looking for.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Raspberry Pi Imager 1.9.4 released bringing performance improvements, bug fixes and more by David Uzondu Raspberry Pi Imager 1.9.4 is now out, marking the first official release in its 1.9.x series. This application, for anyone new to it, is a tool from the Raspberry Pi Foundation. It first came out in March 2020. Its main job is to make getting an operating system onto a microSD card or USB drive for any Raspberry Pi computer super simple, even if you hate the command line. It handles downloading selected OS images and writing them correctly, cutting out several manual steps that used to trip people up, like finding the right image version or using complicated disk utility tools. This version brings solid user interface improvements for a smoother experience, involving internal tweaks that contribute to a more polished feel. Much work went into global accessibility, adding new Korean and Georgian translations. Updates also cover Chinese, German, Spanish, Italian, and many others. Naturally, a good number of bugs got squashed, including a fix for tricky long filename issues on Windows and an issue with the Escape key in the options popup. Changes specific to operating systems are also clear. Windows users get an installer using Inno Setup. Its program files, installer, and uninstaller are now signed for better Windows security. For macOS, .app file naming in .dmg packages is fixed, and building the software is more reliable. Linux users can now hide system drives from the destination list, a great way to prevent accidentally wiping your main computer drives. The Linux AppImage also disables Wayland support by default. The full list of changes is outlined below: Fixed minor errors in Simplified Chinese translation Updated translations for German, Catalan, Spanish, Slovak, Portuguese, Hebrew, Traditional Chinese, Italian, Korean, and Georgian Explicitly added --tree to lsblk to hide partitions from the top-level output CMake now displays the version as v1.9.1 Added support for quiet uninstallation on Windows Applied regex to match SSH public keys during OS customization Updated dependencies: libarchive (3.7.4 → 3.7.7 → 3.8.0) zlib (removed preconfigured header → updated to 1.4.1.1) cURL (8.8 → 8.11.0 → 8.13.0) nghttp2 (updated to 1.65.0) zstd (updated to 1.5.7) xz/liblzma (updated to 5.8.1) Windows-specific updates: Switched to Inno Setup for the installer Added code signing for binaries, installer, and uninstaller Enabled administrator privileges and NSIS removal support Fixed a bug causing incorrect saving of long filenames macOS-specific updates: Fixed .app naming in .dmg packages Improved build reliability and copyright Linux-specific updates: System drives are now hidden in destination popup Wayland support disabled in AppImage General UI/UX improvements: Fixed OptionsPopup not handling the Esc key Improved QML code structure, accessibility, and linting Made options popup modal Split main UI into component files Added a Style singleton and ImCloseButton component Internationalization (i18n): Made "Recommended" OS string translatable Made "gigabytes" translatable Packaging improvements: Custom AppImage build script with Qt detection Custom Qt build script with unprivileged mode Qt 6.9.0 included Dependencies migrated to FetchContent system Build system: CMake version bumped to 3.22 Various improvements and hardening applied Removed "Show password" checkbox in OS customization settings Reverted unneeded changes in long filename size calculation Internal refactoring and performance improvements in download and extract operations Added support for more archive formats via libarchive Lastly, it's worth noting that the system requirements have changed since version 1.9.0: macOS users will need version 11 or later; Windows users, Windows 10 or newer; Ubuntu users, version 22.04 or newer; and Debian users, Bookworm or later.
    • Ancient CD app makes 64-bit comeback to support Windows 11 and probably Windows 10 too by Sayan Sen Remember when CDs or compact discs were a thing? While technically, they still are, their popularity and usage have dropped immensely with the rise in other standards like USB, as the latter continues to evolve, getting faster and gaining more features. Recently, Microsoft enforced some mandatory requirements for USB Type-C so as to ensure a uniform and consistent experience for Windows 11 users. On the topic of Windows 11 and CDs, a CD ripping tool from the Windows 95/98 era, dubbed "CD2WAV32," is back again after 16 years (from the Windows 7 era). The utility has now been updated to work on Windows 11 version 24H2, which is pretty cool. This was not planned, says the author, as they simply wanted to test the app on their newly upgraded Windows 11 PC, but ended up going all the way to make it fully work on Windows 11. Their Windows 11 runs an AMD Ryzen 9600X, 64 GB RAM, and an Nvidia GT 1030 (miswritten as "GT1300"). The developer of the tool notes that they did not run thorough tests on Windows 10, but it works on their Atom-based PC, which is another relic, given how fast technology moves. The author writes (Google-translated from Japanese to English): "From now on, it will only support Windows 11 (24H2). The reason is that this is the only environment the author currently has. I haven't done anything particularly fancy, so I think it will work properly on Windows 10, but I can't guarantee it. All I have left is an ATOM machine that I bought a long time ago that also runs Windows 10, so I've seen that it works lightly on that, but I can't do a detailed test." Atom, for those wondering, was Intel's low-power CPU lineup that it decided to axe back in 2016. The story is similar to how Microsoft gave up on Windows Lumia, as Intel, too, abandoned its mobile chip ambitions once the likes of Qualcomm and MediaTek took over. In terms of the underlying changes, the utility has been compiled now on Delphi 12.1 Community Edition, which is used to make native Windows apps as well as ones for macOS, iOS, and Android. The recent update also brings a significant overhaul in terms of compatibility as well as UX/UI. File sizes and other such metadata are now handled using a 64-bit format instead of the prior 32-bit approach, eliminating overflow issues and ensuring large file and disk space values are displayed correctly. This change is necessary given that large storage volumes are quite common these days. Additionally, support for 16-bit code calling functions has been entirely removed as Windows 11 is 64-bit only; thus, features like MSCDEX and TwinVQ compression are gone. Meanwhile, the font has been changed from MSP Gothic 9pt to Meiryo 10pt, so readability should not be a problem even on 4K screens. In terms of audio file encoding support, it is said to work with MP3 as well as WMA. So, should you download and run it? Probably not, given that the UI is entirely Japanese, but it is still a fun project to look at.
    • Xbox has lots of games… and there all coming to Playstation!
    • Athena was the goddess of wisdom and war interesting choice
  • Recent Achievements

    • Week One Done
      jbatch earned a badge
      Week One Done
    • First Post
      Yianis earned a badge
      First Post
    • Rookie
      GTRoberts went up a rank
      Rookie
    • First Post
      James courage Tabla earned a badge
      First Post
    • Reacting Well
      James courage Tabla earned a badge
      Reacting Well
  • Popular Contributors

    1. 1
      +primortal
      397
    2. 2
      +FloatingFatMan
      177
    3. 3
      snowy owl
      170
    4. 4
      ATLien_0
      167
    5. 5
      Xenon
      134
  • Tell a friend

    Love Neowin? Tell a friend!