If you want jfghirehgirl to mean Hello world 5555 hello world google, then you could just use a hash or dictionary:
NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys: @"Hello world 5555 hello world google", @"jfghirehgirl", nil];
Then, looking up jfghirehgirl will give you the original longer string.
A classic substitution based compression.
If you want an algorithmic transformation, gzip is about the best easily accessible general purpose compression algorithm. It also happens to be supported "on the wire" by most common protocols. Given the lack of context, hard to say more.
OK -- finally -- a concrete question:
like
"AmfkF04njgfdlnre4wp[fnv4s/sif03jgndlkrjrtyuiocvbnjm78dcfghjk89tgb
dfgyhuic89vbnyhncvghj8ujmokjnfgbijk98nfgh0978njvcg9h08065yejktgb45ncvghyuitg45hnmpokjnb65yhjcvgf4354g3hjok/mnbcfghjkuh45jcfgh45dfv23bn"
(200 charecters)
That looks an awful lot like you banged on the keyboard. I.e. there is no signal there; it is white noise. White noise, by its very nature, does not compress.
Sure enough, copying that and doing this in terminal:
pbpaste | gzip --best -f | wc -c
121
Yields 121 characters. You might think 200 -> 121 is decent compression. It isn't; that is just the bits of the characters compressing. Since SMS has a limited character set, the result can't be used anyway. So, you'd need to encode it back to ASCII using something like base64.
I.e:
pbpaste > /tmp/foo
python
>>> x = file('/tmp/foo','r').read()
>>> len(x)
121
>>> y = b64encode(x)
>>> len(y)
164
164 characters. Not bad; maybe even usable (barring for the moment that you can neither read nor compose SMS messages programmatically on the iPhone, but the user could copy/paste).
So -- gzip, then base64 encode is the concrete answer given the contrived signal. A better answer could be given if the signal were more like the real signal you are going to send.
