FROM : m
DATE : Fri Nov 22 18:41:20 2002
Dan Wood meinte doch tatsdchlich:
>> we're currently writing a text-conversion plug-in for our app, and
>> are quite unsure which encoding to choose. :)
>> we got plaintext to start with and would like to export these texts
>> to unix-, mac-, windows-, unicode-format. now... these are our
>> options:
>
> You'll probably best off supporting all of the formats, and letting
> the user decide what they want. Everybody is going to have different
> needs; perhaps you could take the most common ones and present them
> first. (If you look in the documentation and header comments, you'll
> probably find the official names of these encodings.)
uh... but how can the user tell which encoding is the right one? see,
*i* wouldn't know without your help. ;)
but thanks alot for the explanations of the various encodings. i'm not
too sure about this japanese stuff, because a) i'd love to see our app
in japan, but b) dunno if there's any market for it <ggg>.
whatever...
>> NSUTF8StringEncoding = 4,
>> NSISOLatin1StringEncoding = 5,
>> NSUnicodeStringEncoding = 10,
>> NSMacOSRomanStringEncoding = 30,
k, so that's about it.
thanks again.
>> some seem obvious, but some just don't. :)
>>
>> anybody care to shed some light on this?
>>
>> or are we heading in a completely wrong direction?
>
> I think you're probably doing the right thing. Take a look at how
> TextEdit works for opening files and saving files, that should give
> you and idea of what makes sense. If you are reading text that comes
> from an arbitrary source, you need to support as many encoding formats
> as possible. Internally, the text will be stored as unicode. Then,
> if you are writing it out, and the user might want to write it out in
> a different format, you should give them plenty of options.
yeah. that's what they'll get. :)
> Also, be sure to handle Unix, mac, and Windows end-of-line
> encodings.... \n, \r, and \r\n respectively. Somebody opening a file
> in Mac format and saving it in Windows format is going to want to have
> your program do the right thing....
what's with this \n, \r, \r\n? unix, mac, win, right?
unicode has \n?
and do we need to replace line-endings, too, when we're switching the
encoding? we thought that the encodings would take care of that one way
or the other... <g>
greetz
mahakk
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Fri Nov 22 18:41:20 2002
Dan Wood meinte doch tatsdchlich:
>> we're currently writing a text-conversion plug-in for our app, and
>> are quite unsure which encoding to choose. :)
>> we got plaintext to start with and would like to export these texts
>> to unix-, mac-, windows-, unicode-format. now... these are our
>> options:
>
> You'll probably best off supporting all of the formats, and letting
> the user decide what they want. Everybody is going to have different
> needs; perhaps you could take the most common ones and present them
> first. (If you look in the documentation and header comments, you'll
> probably find the official names of these encodings.)
uh... but how can the user tell which encoding is the right one? see,
*i* wouldn't know without your help. ;)
but thanks alot for the explanations of the various encodings. i'm not
too sure about this japanese stuff, because a) i'd love to see our app
in japan, but b) dunno if there's any market for it <ggg>.
whatever...
>> NSUTF8StringEncoding = 4,
>> NSISOLatin1StringEncoding = 5,
>> NSUnicodeStringEncoding = 10,
>> NSMacOSRomanStringEncoding = 30,
k, so that's about it.
thanks again.
>> some seem obvious, but some just don't. :)
>>
>> anybody care to shed some light on this?
>>
>> or are we heading in a completely wrong direction?
>
> I think you're probably doing the right thing. Take a look at how
> TextEdit works for opening files and saving files, that should give
> you and idea of what makes sense. If you are reading text that comes
> from an arbitrary source, you need to support as many encoding formats
> as possible. Internally, the text will be stored as unicode. Then,
> if you are writing it out, and the user might want to write it out in
> a different format, you should give them plenty of options.
yeah. that's what they'll get. :)
> Also, be sure to handle Unix, mac, and Windows end-of-line
> encodings.... \n, \r, and \r\n respectively. Somebody opening a file
> in Mac format and saving it in Windows format is going to want to have
> your program do the right thing....
what's with this \n, \r, \r\n? unix, mac, win, right?
unicode has \n?
and do we need to replace line-endings, too, when we're switching the
encoding? we thought that the encodings would take care of that one way
or the other... <g>
greetz
mahakk
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| m | Nov 22, 14:21 | |
| Dan Wood | Nov 22, 16:59 | |
| m | Nov 22, 18:41 |






Cocoa mail archive

