Re: Problem with japanese systems [Solved?]
Re: Problem with japanese systems [Solved?]
- Subject: Re: Problem with japanese systems [Solved?]
- From: Mark Williams <email@hidden>
- Date: Sun, 24 Jul 2005 20:51:06 -0700
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!
Messenger - 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:
This email sent to email@hidden