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: Mark Williams <email@hidden>
- Date: Sun, 24 Jul 2005 22:40:08 -0700
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.
On Jul 24, 2005, at 10:13 PM, John Stiles wrote:
I'm glad it's no longer failing. Still, though, why do you feel a
need to convert it to an NSString at all? The data in question
really isn't a string, so it's kind of baffling that you keep
treating it as such. Just use NSData.
Mark Williams wrote:
Okay I've rewritten the method in question to read the file into
an NSData object and then that in turn into an NSString with
explicit encoding. And according to the Japanese gentleman
testing, who sends me a data file the app creates when it fails,
this was the answer. There is still a bug but thanks to the info
you all gave me and especially the info in this email, I think I
should have it working tonight.
Mark.
P.S. If I had used md5 or apple's hashing then I'd have never
learned what I have learned today. So I think it's better that I
had this all mickey moused to begin with.
On Jul 24, 2005, at 8:08 PM, ObjM2 wrote:
sorry, forgot to include the list ...
AM wrote:
Ok, I understand what your asking. Let me try to give you some
more info
without exposing my hiney too much.
I do understand that it is not valid as a string however you
can read the
file into a string.
The program in question reads this file and creates a short
string of
data based on it. kind of like a hash.
Well it has always worked until suddenly since 10.4 on mac's
in japanese
the string is an empty string. Not a pointer to null but an empty
string. It only happens when the Executable or a library that
is part of
the app bundle is evaluated, it works fine for all other files
such as
the info.plist, or anything in the resources folder. Or for
that matter
any file on the hd.
First of all, there is no such thing as a "Japanese system".
All MacOSX systems are exactly the same: non-lingual. That's
where your error is.
What you have instead is a user's login environment which has a
default user language according to the user's "International"
preference pane settings in System Preferences.
When you use any of the methods that read data into NSStrings
without specifying an encoding explicitly, then the encoding
used to do the conversion is the encoding associated with the
current user's current user language setting. Note that these
methods are NOW DEPRECATED in favour of methods that require
you to specify the encoding explicitly, precisely for the
reason that what you are doing is wrong and shouldn't be
allowed in the first place ...
Depending on the language settings of the user who runs your
application, your code will produce different results. For most
users who have English set as their user language, the encoding
used is usually NSMacOSRomanStringEncoding. However, don't
count on that. In many cases the results will be unpredictable,
not just if the user has set his language to Japanese.
If you want to create a hash over your application's executable
or any other files to make sure they haven't been tampered
with, use MD5 instead. Run an NSTask with /sbin/md5 as the
command and the path to the file as the parameter to get the
MD5 checksum back.
Also note that Apple's documentation says that their hashing
algorithm is not guaranteed to produce the same return values
across different OS versions. So, even without the variance
introduced by the encoding, you still can't rely on Apple's
hash for what you are likely trying to do.
___________________________________________________________Yahoo! M
essenger - NEW crystal clear PC to PC calling worldwide with
voicemail http://uk.messenger.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:
40fornextsoft.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.com
This email sent to email@hidden
_______________________________________________
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