Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2400
  • Last Modified:

Shortening Base64 string result

Hi,  I just converted the bytes I've read from a file with the Base64 type encryption so to make the bytes look ASCII string.  But the result is a very very very long string,  how can I do to encrypt this string again to make it shorter?
0
AlexMert
Asked:
AlexMert
  • 3
  • 3
  • 2
1 Solution
 
TommySzalapskiCommented:
If you want it to be shorter then, don't use Base64. If you do need it to be an ASCII string, then compress the data (using gzip or any other compression scheme) and then encode the compressed file as Base64. That is as short as you will be able to get it. If it's still too long, then you'll have to refactor something (What is in the file?).
0
 
AlexMertAuthor Commented:
I don't want in no way to change the extension of the file or to depend by anything( cause only gzip can decompress it back so... ) And I don't do this for a specific file, it can be anything, and yes, I need at the final the result to be ASCII text
0
 
ozoCommented:
I need at the final the result to be ASCII text
Does that mean you can use any of the 128 ASCII characters rather than the 64 characters in the Base64 character set?  If so, you can reduce the size by 6/7
Does ASCII text mean you can use any of the 95 printable ASCII characters?
If so, you can, with a little more difficulty, reduce the size by not quite 21/23
0
Cyber Threats to Small Businesses (Part 1)

This past May, Webroot surveyed more than 600 IT decision-makers at medium-sized companies to see how these small businesses perceived new threats facing their organizations.  Read what Webroot CISO, Gary Hayslip, has to say about the survey in part 1 of this 2-part blog series.

 
AlexMertAuthor Commented:
Yes any ASCII symbol :) anything ! But to be ASCII ! And short ! Thanks !
0
 
TommySzalapskiCommented:
In order to get it much shorter, you will need to have some kind of compression. Adding the other 31 printable ASCII characters (as Ozo mentions) is only going to save you less than 10%.

What is the data representing? Do you control both the sender and the receiver? If so, you should be able to develop your own system for compressing the data.

You shouldn't be afraid of gzip or other third party utilities. You can build them into your application so you don't need to use them separately.
0
 
ozoCommented:
I'm also wondering about the exact requirements here.
NUL and DEL are technically ASCII characters, but most situations that would allow their arbitrary use would also be able to handle 8 bit character sets.
What exactly is the cause for the need to restrict the character set?  This might clarify which symbols can be allowed and which cannot.
What makes dependence on a Base64 encoder (and I'm presuming you mean encoding and not encryption) acceptable, but dependence on gzip not acceptable?  What are the acceptable options we have to work with to construct a more compact representation?
And what is the nature of the source file?   Compression methods that are tuned to the particular characteristics of particular sets of data can usually do better than general purpose compression.
0
 
AlexMertAuthor Commented:
Look. For example I want to read all the bytes from a Video File Type. Then I want to turn them into text , or ASCII to send them as that over the internet, then who receives this 'very long string' to take it back and transform or decrypt it back to the exact same bytes that that video had, basically I transfered the video to that person, but not in a binary format but in characters .

 The problem is that it must work with ANY file type and the string resulting after transforming the bytes into ASCII via Base64 is very very long ! I need somehow to encrypt or encode ( don't know whats the difference ) again that string to a more compact string .
0
 
ozoCommented:
The internet is an 8 bit medium, so the requirement for ASCII is still unexplained.
If the Base64 encoding is very very long, that means that the original file was very very long, and an 8 bit encoding, while 6/8 smaller than a Base64 encoding, would also be very very long.
If the purpose is to send over the internet, perhaps a URL to the file can be sent rather than an encoding of the file.
Compact URLs can be generated, for example, here http://tinyurl.com/
Another option may be to break up one very very long string into many very long strings,
or into many many long strings.
To compact by more than 6/8 or 6/7 or 21/23, it would be better to do video compression on the original file before ASCII encoding,
Then you might try a slightly more compact encoding such as Base85 http://en.wikipedia.org/wiki/Ascii85  or basE91 http://base91.sourceforge.net/ or yEnc http://www.yenc.org/yenc-draft.1.3.txt
0

Featured Post

Cyber Threats to Small Businesses (Part 1)

This past May, Webroot surveyed more than 600 IT decision-makers at medium-sized companies to see how these small businesses perceived new threats facing their organizations.  Read what Webroot CISO, Gary Hayslip, has to say about the survey in part 1 of this 2-part blog series.

  • 3
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now