Hey, No one is requiring me to send a string–I do indeed send it as data, but I must convert values from string to data. Like, I have a title field, in which I must convert the title to NSData. But since there are a bunch of arguments like this, I just make a string like @"arg1=something&arg2=something...", and then do [dataUsingEncoding:allowLossyConversion:.
Should I be doing this a better way? (I'm the one who created the web service, so if there's an issue with doing it this way, I can easily change it). Joe On Jul 23, 2010, at 11:31 AM, Kyle Sluder wrote: > On Fri, Jul 23, 2010 at 9:22 AM, Joe Turner <joetur...@me.com> wrote: >> The reason I need to convert it to a string is to put it into the post >> string of a url request. However, would it be possible instead to just use >> NSMutableData, and just append this data block where it needs to go? That >> way, I wouldn't have to deal with NSStrings and encoding. > > POST data is urlencoded data; NSString should never be involved. For > example, NSMutableURLRequest has a -setHTTPBody: method which takes an > NSData, not an NSString. > > Who is requiring you to provide an NSString? This is where the fault lies. > > --Kyle Sluder > >> >> Joe >> On Jul 22, 2010, at 9:49 PM, Kyle Sluder wrote: >> >>> On Thu, Jul 22, 2010 at 6:25 PM, Joe Turner <joetur...@me.com> wrote: >>>> I'm having an issue with NSPropertyListSerialization, where I will call >>>> dataWithPropertyList:format:options:error:, to get the data from a >>>> property list–this part goes fine. However, then I need the data as a >>>> string, so I can upload it to a web service. However, when I call >>>> initWithData:encoding: to get a string (I'm using NSASCIIStringEncoding, >>>> but have tried many others as well), wherever there was a letter with an >>>> accent, weird stuff happens. Like é turns into Ä. I'm fine with losing >>>> accents, but right now, I can't even seem to do that–I just get the Ä's. >>>> Is there any way I can use a different encoding or something else to keep >>>> the accents for the time being, and then filter them out when I create the >>>> post data with dataUsingEncoding:allowLossyConversion:? >>> >>> There are two potential encoding mismatches here: >>> >>> 1) The encoding of the serialized plist vs. the encoding you pass to >>> -initWithData:encoding: >>> 2) The encoding of the data you send to the web service vs. the >>> encoding the service is expecting to receive >>> >>> You need to make sure that both of these situations are handled correctly. >>> >>> As James says, the "standard" (more accurately, "assumed by default") >>> encoding of XML is UTF-8. But you can do even better than that, if you >>> like, since the only logical choice for plist format in this case is >>> XML: you can check the encoding of the serialized plist by creating an >>> NSXMLDocument out of it and asking for its -characterEncoding. While I >>> doubt that NSPropertyListSerialization is ever going to start emitting >>> XML documents that are not UTF-8 encoded, this is the most correct >>> approach. >>> >>> Either way, that gives you the answer for what encoding you should be >>> passing -initWithData:encoding:. But I'm kind of curious why you're >>> bothering to convert it to a string in the first place, since it can't >>> possibly be of any benefit to you. NSString's internal representation >>> is UTF-16 anyway, so the first thing -initWithData:encoding: is going >>> to do is convert your XML document (with its encoding="utf-8" header!) >>> into UTF-16. Then at some point down the line you'll need to ask for >>> the data back in UTF-8 format, or else you'll wind up with a lying >>> encoding directive. >>> >>> Long story short, it sounds like you're abusing NSString. Data are not >>> the strings, and strings are not data; Cocoa is designed to keep the >>> two concepts separate. >>> >>> --Kyle Sluder >> >> _______________________________________________ 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 arch...@mail-archive.com
