Re: Problem with japanese systems [The Why of all this]
Re: Problem with japanese systems [The Why of all this]
- Subject: Re: Problem with japanese systems [The Why of all this]
- From: ObjM2 <email@hidden>
- Date: Mon, 25 Jul 2005 17:10:31 +0900
On Jul 25, 2005, at 2:40 PM, Mark Williams wrote:
The reason I do not use the NSData... Well I cannot explain exactly
why or I'd be telling you how I create the hash and then I'd have
to reinvent that particular wheel. But the reason I insist on
continuing to read the data in to a string is that I couldn't
figure out how to get the function to correctly perform operations
on each individual byte. What I was trying to do simply did not
work and this includes using subdata methods and passing a range of
index,1 to work one byte at a time. I could not convert the bytes
into something I could use the way I needed to use them and I gave
up. To this day I cannot get it to work right, though I will admit
I have not worked with it in a few months.
Well, you better try again and perhaps post here to ask about any
stumbling blocks you may run into because using NSString as an
intermediary format means your code remains broken. Just because the
test you carried out came back without an error doesn't mean that
your code will work elsewhere or will work on a different data set.
There are a vast number of code points in the various encoding
schemes to which no character is assigned, in particular in the multi-
octet based character sets used by Asian languages. You can't just
assume that an arbitrary data stream will not contain any data that
represents an unassigned code point in the encoding used.
Remember, that the methods which convert data into NSStrings have to
use an encoding scheme, whichever one is used, explicitly or
implicitly. If there is any data that does not correspond to a valid
octet or multi-octet in the encoding used, then the return value will
be nil.
Also, the fact that you have invested effort in a scheme on your own
which is apparently flawed, is not a good reason to continue using
it. You should consider migrating your code to using MD5. If you
don't like to call an external program (/sbin/md5) you can always rig
your own MD5 code. It is not only well documented, but there are
several MD5 functions in C source code around on the net. There are
other such algorithms, too. For example SHA1.
Those algorithms are continuously tested by the world's best
cryptography experts. If you use them, you get all that expertise
with it. Rolling your own means that you made it very easy for
anybody who seriously wants to circumvent whatever you are trying to
secure. Security through obscurity simply does not work. Consider
this: There are people who find undocumented Cocoa methods, find out
what those methods do and reengineer their signatures, all through
using debugging tools. Do you honestly think if somebody wanted to
bypass whatever it is you're doing that your private algorithm is
going to stop them? Don't be so naive.
rgds
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden