On May 6, 2008, at 10:56 AM, Jens Alfke wrote:
On 6 May '08, at 7:03 AM, Thomas Engelmeier wrote:
As the OP wants to create NSStrings with data created by his
application I'm pretty sure he will not want the the Windows
encoding - unless he parses text documents originating from Windows.
He didn't say where the data originates from, or what those APIs are
that return the strings. If they're networking APIs, the data could
very likely have originated on Windows.
Also, you missed my point about using CP1252 (WinLatin1). It's
useful as a fallback for any unknown C strings because (a) it's a
superset of ISO-Latin-1, which (b) has no gaps in it (as ISO does,
from 0x80-0x9F), so decoding text into an NSString will never fail
and return nil. (I've debugged several crashes that stemmed from nil
NSStrings decoded from garbage strings.)
This is not entirely true.
windows1252 (CP1252) also has "holes" in it (undefined characters).
Definitely attempt to find out what platform or platforms data will
come from. It's often the case where your app needs "legacy" import
features to work with the most common older Mac/Windows encodings.
Many apps offer "previews" of text that is to be imported. Complex
algorithms exist to determine an encoding from a block of text, but
sometimes it's best to let users drive the show (i.e. let them pick an
encoding and see if their preview looks valid).
___________________________________________________________
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
