Closed TilmanGriesel closed 12 years ago
Just to be clear, readUTFBytes is "decoding" from a raw binary array into a UTF string. encodeURIComponent is encoding that string to a URI safe format. Neither UTF8 nor raw binary data can cross the Javascript/Actionscript barrier.
Okay, i use only the flash Websocket class and not the Javascript part. I wonder why the char "ö" will be received as "ö". Looks like double encoded so i searched for the reason. After i see the readUTFBytes (which decodes the data in the UTF format) and the encodeURIComponent (which converts the complete URI to UTF-8) part I thought that was the problem. I removed the second call and the special chars are passing fine from client to client.
Ah, if you're not using the Javascript part then you may be missing the decodeURIComponent on the other side which would result in the wrong "encoded" data.
okay cool all good. i thought that you have implemented the decode part in the js part of the lib. Have a nice day :)
That's currently the right way. But I think the current ActionScript API is weird that user need to decode manually. I'm thinking of changing it (perform URI encoding just before passing to JS).
It was true that we needed URI encoding when we used FABridge. But I'm not sure whether it's still true using ExternalInterface directly. @kanaka, have you confirmed that it is still needed?
@gimite, it's been a while since I was working on that (for binary support), but as I recall, I think that ExternalInterface is actually used under the covers to implement FABridge and it is a limitation of ExternalInterface that dictates the use of encoding/decoding in order to send data. But it's worth testing again since I don't remember for sure. And it may be that newer versions of Flash may improve the interface.
I see, thanks. I'll try.
After sending chat messages trough the WebSocket I experienced some issues with UTF8 chars (e.g german umlauts). I found the encodeURIComponent call which encodes the message data to UTF8 and the readUTFBytes call (which encodes the message as well). Both will be called on the same data what leads to double encoding. I removed the encodeURIComponent call and fixed the issue by that.