FROM : Alastair Houghton
DATE : Fri Jan 25 18:10:48 2008
On 25 Jan 2008, at 11:29, Hans van der Meer wrote:
> I extended NSData with a category in order to implement NSData
> payload compression, using zlib. That works fine for data for which
> I know its length, but seems more difficult in case of objects. Like
> for example NSString's, in which I am especially interested in
> compressing them.
>
> I could think of two procedures:
> (1) using the archiver to pack the NSString into a NSData object
> from which I can retrieve the payload and then compress it
> (2) dump the NSString contents into an array with getCharacters,
> compress that array and then put it inside a NSData object
>
> However, both procedures need a (seemingly unnecessary) extra step I
> would like to avoid. If it were possible to find the bytesize of
> objects, I could do the compression directly on it.
>
> My question thus: is it possible to retrieve the actual bytesize of
> an object? Or is there another solution to the above compression
> problem which I am overlooking?
At the risk of echoing Ken Thomases, you are trying to skip a step
that is actually crucial if you want to:
1. Avoid having to handle endianness *and structure packing* issues
yourself.
2. Ensure that your data on disk is in a known and supported format.
3. Deal properly with pointers held inside objects.
In the particular case of NSString, you can encode it using its own
methods as character data in a particular encoding. Its internal
representation can and does vary considerably depending on how it was
created (you can see this from the source code, which is in the CFLite
project that Apple released as Open Source; NSStrings are just
CFStrings, after all).
In the more general case, you should use the Cocoa archiving support
via an NSCoder of some description. Once you have an NSData, you can
then compress it.
Kind regards,
Alastair.
--
http://alastairs-place.net
DATE : Fri Jan 25 18:10:48 2008
On 25 Jan 2008, at 11:29, Hans van der Meer wrote:
> I extended NSData with a category in order to implement NSData
> payload compression, using zlib. That works fine for data for which
> I know its length, but seems more difficult in case of objects. Like
> for example NSString's, in which I am especially interested in
> compressing them.
>
> I could think of two procedures:
> (1) using the archiver to pack the NSString into a NSData object
> from which I can retrieve the payload and then compress it
> (2) dump the NSString contents into an array with getCharacters,
> compress that array and then put it inside a NSData object
>
> However, both procedures need a (seemingly unnecessary) extra step I
> would like to avoid. If it were possible to find the bytesize of
> objects, I could do the compression directly on it.
>
> My question thus: is it possible to retrieve the actual bytesize of
> an object? Or is there another solution to the above compression
> problem which I am overlooking?
At the risk of echoing Ken Thomases, you are trying to skip a step
that is actually crucial if you want to:
1. Avoid having to handle endianness *and structure packing* issues
yourself.
2. Ensure that your data on disk is in a known and supported format.
3. Deal properly with pointers held inside objects.
In the particular case of NSString, you can encode it using its own
methods as character data in a particular encoding. Its internal
representation can and does vary considerably depending on how it was
created (you can see this from the source code, which is in the CFLite
project that Apple released as Open Source; NSStrings are just
CFStrings, after all).
In the more general case, you should use the Cocoa archiving support
via an NSCoder of some description. Once you have an NSData, you can
then compress it.
Kind regards,
Alastair.
--
http://alastairs-place.net
| Related mails | Author | Date |
|---|---|---|
| Hans van der Meer | Jan 25, 12:29 | |
| Ken Thomases | Jan 25, 17:38 | |
| Alastair Houghton | Jan 25, 18:10 |






Cocoa mail archive

