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


Reply via email to