Thank you very much for your detailed answer. I'm Ok with you an I will try what you suggest.
But what I definitely don't understand is why the classes that are supposed to help us don't work. I'm only doing basic operation so what is the cause of this ? For example, as I explained earlier URLVariables (which normally will take care to urlencode the data) encode it bad so I must use the escape function and do it myself. Can I configure the default charset for the app to avoid this workaround ? For my NetConnection.call() which Invokes a method defined on a Client object in Server-Side ActionScript, I'm quite sure that normally the encoding is managed internally by this function. And I have never seen in documentation a hand made encoding like you suggest. What am I missing ? What am I doing wrong so that native functions who are aimed to that job don't do it ? 2013/8/29 Julio Carneiro <ju...@4ctv.com> > Let me try to add my thoughts on the topic. > > If you want to send/receive non-ascii characters, both parties in the > communication must agree on an encoding (or send the encoding format on the > stream as in XML). > > Also, you must send/receive data in binary format. All common > communication protocols were devised to transfer 'text' in ascii format, > that's why some protocols need to escape non-ascii chars on the stream > (html, http requests, even XML). > > For example if your stream is XML, you must wrap your non-ascii test into > a CDATA element content, and to be 100% sure data will be accurate on both > sides you should encode your binary text in something like Base64, which is > pure ascii. > > Please note that although you can specify UTF-8 encoding for your XML, you > cannot use non ascii characters as element names, or as attribute names or > values!! > Same for HTML data. Tags, attributes and attribute values must be pure > ascii. Non-ascii encoding is only valid as element/tag content. > > You did not mention what kind of server you have, or if you have control > of the protocol/format/encoding of the communication. If you do, I'd > suggest you use the following to send your data: > - treat your TextInput.text value as a binary value > - move it to a ByteArray, using ByteArray.writeUTF() > - encode it to base64 > > On the receiving side (server or client) do the opposite: > - decode a bas64 text into a ByteArray > - extract your data using ByteArray.readUTF() > > Doing it that way you avoid any encoding, escaping, or other issues in the > underlying communication mechanism you're using. That technique will ensure > the data stream is always pure ascii. > > hth > julio > > On Aug 29, 2013, at 11:57 AM, manitas manitas <manitas0...@gmail.com> > wrote: > > > Thank you for those information about trace. > > Alex Haruy already told me that we can't rely on it and now it is sure > ;-) > > > > Nevertheless my main problem is concerning the transfer of a string using > > NetConnection.call() > > > > The remote server is waiting for utf-8 encoded data, do you know how can > I > > encode my input string in utf-8 ? > > > > > > > > > > 2013/8/29 Mark Line <markl...@gmail.com> > > > >> That is weird. I just traced the same thing in Flash builder 4.7 using: > >> Apache Flex 4.9.0 FP11.5 AIR3.5 en_US > >> > >> And it worked " éàçè " > >> > >> -----Original Message----- > >> From: Peter Ginneberge [mailto:p.ginnebe...@gmail.com] > >> Sent: 29 August 2013 15:40 > >> To: users@flex.apache.org > >> Subject: Re: Pb with special characters and accents > >> > >> There's definately an SDK (or flash player?) related bug regarding > trace(). > >> With some SDK's, tracing special characters works fine in others it > >> doesn't (using the same FlashBuilder version). > >> > >> var chars:String = "éàçè"; > >> trace(" - characters: ", chars); > >> > >> > >> SDK 4.1: > >> // Constole output > >> - characters: éàçè > >> > >> SDK 4.5.1: > >> // Console output > >> - characters: ��� > >> > >> Not sure what will turn up in the email, but the above shows 3 squares. > >> > >> SDK 4.9.1 > >> // Console output > >> - characters: éàçè > >> > >> I don't have 4.10 installed (because AIR 3.8 is broken), so I can't test > >> with 4.10 atm. > >> > >> > >> ----- Original Message ----- > >> From: "Mark Line" <markl...@gmail.com> > >> To: <users@flex.apache.org> > >> Sent: Thursday, August 29, 2013 3:19 PM > >> Subject: RE: Pb with special characters and accents > >> > >> > >> I think é is turning into é because trace() only outputs in UTF-8 > while > >> the input of is probably in latin1. Which means the way the characters > are > >> stored as binary data with differ. > >> > >> I don't think you will get a bug fixed or similar trace is just a low > level > >> function of flash player used for debugging/development. > >> > >> Maybe write your own logger? That's what I currently do in a large > project > >> and dependant on the target (fp/air/mobile) do different things with the > >> output. EG on Air create a rolling log file > >> > >> -----Original Message----- > >> From: manitas manitas [mailto:manitas0...@gmail.com] > >> Sent: 29 August 2013 12:26 > >> To: users > >> Subject: Re: Pb with special characters and accents > >> > >> Thank you so much Mark, it works with the escape function. > >> > >> This workaround works but doesn't help me to understand the whole thing, > >> does it means URLVariables use a different default charset ? how to > change > >> it ? Is it relevant create a bug report for that ? > >> > >> and I still have my 2 others questions : > >> Why the output of trace("omé") is omé ? Is it relevant create a bug > >> report > >> for that ? > >> Where I can find documentation to know how to manage charset in a flex > app > >> ? > >> > >> Thanks in advance for your support. > >> > >> > >> > >> > >> > > -- > Julio Carneiro > > >
