You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by Marcus Fritze <ma...@googlemail.com> on 2015/11/02 11:13:42 UTC
serious problem with FileReferenceList in Chrome on Mac
Hi,
actually I have a serious problem with FileReferenceList in Google Chrome on (every) Mac.
When I try to upload files with FileReferenceList in my flex application, the file names are not correct. Umlauts (ä, ö, ü) and other special characters (å) are not correctly „parsed“.
For example, when I upload
Test_äöü.pdf
my flex application recognizes the file name
Test_aou.pdf
So, when I create a new test-project, were I use FileReferenceList and try to test this issue, this error doesn’t occur. So I think it must be related to my generated project. I have no idea, what I can do.
Any help?
Thanks.
Marcus Fritze
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Marcus Fritze <ma...@googlemail.com>.
Thank you so much for all the information.
Tomorrow, I will check what comes in at the server-side, when I upload the file.
Thanks. :-)
> Am 03.11.2015 um 19:01 schrieb Alex Harui <ah...@adobe.com>:
>
> Oh, I forgot to add that one reason to send the 776 to the server and ask
> for the corrected filename is because I think you may find an existing
> PunyCode library for Java that would do the mapping.
>
> On 11/3/15, 9:59 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>> On 11/3/15, 9:43 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>>
>>> Thanks for the advice. It’s maybe the quickest fix to create a
>>> ActionScript function that fixes the file name of any selected file
>>> before I upload a file to the server.
>>>
>>> But seems to be a lot of work, to fix all the allowed UFT-8 characters
>>> which are allowed in file names.
>>
>> I only did enough digging to find the two links. I don’t know if it is
>> better to fix the file names before upload, or ask the server for a
>> corrected file name before displaying it to the user. There might be
>> existing code that will fix the UTF-8 in browsers or in JavaScript that
>> you could call via ExternalInterface. There might be an ActionScript
>> conversion. Or you might be able to get away with a simple test for the
>> 776 character and have a table of replacements.
>>
>>>
>>> Please, correct me if I am wrong, but this is a Google Chrome issue,
>>> right? Should I file a issue for Chrome?
>>
>> There might be more than one issue here. IMO, Flash should properly
>> display the string with the 776 character. I’d be surprised if there
>> isn’t already an issue filed against Chrome, but I would expect their
>> answer to be that they are doing the “right” thing. I’m not an expert in
>> this stuff, but it isn’t clear to me that it is “wrong” to not use 228 in
>> a UTF-8 app, especially if there are algorithms out there that do
>> sorting/collation based on breaking out the diacritics, or for making
>> valid URLs.
>>
>> Good luck,
>> -Alex
>>
>
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Alex Harui <ah...@adobe.com>.
Hi Marcus,
Thanks for all of this info. In order to change the FileReference docs you will need to ask Adobe by filing a bug at bugbase.adobe.com as those classes are part of the Adobe runtimes.
Thanks,
-Alex
From: Marcus Fritze <ma...@googlemail.com>>
Reply-To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
Date: Wednesday, November 11, 2015 at 5:50 AM
To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
Subject: Re: serious problem with FileReferenceList in Chrome on Mac
I want to give a quick update about this issue for everybody who is interested. Or everybody who has a Mac. ;-)
In Unicode there are four different normalization forms: NFD, NFC, NFKD, NFKC
(english) https://en.wikipedia.org/wiki/Unicode_equivalence
(german) https://de.wikipedia.org/wiki/Normalisierung_(Unicode)
That means, for example the letter ä is different in NFC and NFD.
NFC = ä (00E4)
NFD = a (0061) + ̈ (0308)
Now comes the tricky part. Mac OS X uses Unicode NFD in the file system. And when I upload a file from OS X
via Chrome (in flash) the file name is still in NFD. Other browsers on OS X „convert“ this file name to NFC.
Here are some related chrome issues:
https://code.google.com/p/chromium/issues/detail?id=125271
https://code.google.com/p/chromium/issues/detail?id=341019
In this issues is not specifically mentioned that this also occurs when uploading files via the Chrome Pepper player.
Maybe, it’s not a bug it’s a feature. ;-)
It seems that NFC is the most used normalization worldwide and it’s recommended to use NFC.
http://unicode.org/faq/normalization.html
http://www.macchiato.com/unicode/nfc-faq
To change the NFD file-name (of my uploaded file on OS X on a Mac) to NFC I use:
https://github.com/rozd/as3-unicode-normalizer
So, everybody who is using FileReference (uploading files) should be aware of this.
Even if you are on Windows and maybe the users of your Flex app are on on Mac.
This case maybe should be mentioned in the FileReference / FileReferenceList docs.
Thanks.
Greetings
Marcus
Am 03.11.2015 um 19:01 schrieb Alex Harui <ah...@adobe.com>>:
Oh, I forgot to add that one reason to send the 776 to the server and ask
for the corrected filename is because I think you may find an existing
PunyCode library for Java that would do the mapping.
On 11/3/15, 9:59 AM, "Alex Harui" <ah...@adobe.com>> wrote:
On 11/3/15, 9:43 AM, "Marcus Fritze" <ma...@googlemail.com>> wrote:
Thanks for the advice. It’s maybe the quickest fix to create a
ActionScript function that fixes the file name of any selected file
before I upload a file to the server.
But seems to be a lot of work, to fix all the allowed UFT-8 characters
which are allowed in file names.
I only did enough digging to find the two links. I don’t know if it is
better to fix the file names before upload, or ask the server for a
corrected file name before displaying it to the user. There might be
existing code that will fix the UTF-8 in browsers or in JavaScript that
you could call via ExternalInterface. There might be an ActionScript
conversion. Or you might be able to get away with a simple test for the
776 character and have a table of replacements.
Please, correct me if I am wrong, but this is a Google Chrome issue,
right? Should I file a issue for Chrome?
There might be more than one issue here. IMO, Flash should properly
display the string with the 776 character. I’d be surprised if there
isn’t already an issue filed against Chrome, but I would expect their
answer to be that they are doing the “right” thing. I’m not an expert in
this stuff, but it isn’t clear to me that it is “wrong” to not use 228 in
a UTF-8 app, especially if there are algorithms out there that do
sorting/collation based on breaking out the diacritics, or for making
valid URLs.
Good luck,
-Alex
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Marcus Fritze <ma...@googlemail.com>.
I want to give a quick update about this issue for everybody who is interested. Or everybody who has a Mac. ;-)
In Unicode there are four different normalization forms: NFD, NFC, NFKD, NFKC
(english) https://en.wikipedia.org/wiki/Unicode_equivalence <https://en.wikipedia.org/wiki/Unicode_equivalence>
(german) https://de.wikipedia.org/wiki/Normalisierung_(Unicode) <https://de.wikipedia.org/wiki/Normalisierung_(Unicode)>
That means, for example the letter ä is different in NFC and NFD.
NFC = ä (00E4)
NFD = a (0061) + ̈ (0308)
Now comes the tricky part. Mac OS X uses Unicode NFD in the file system. And when I upload a file from OS X
via Chrome (in flash) the file name is still in NFD. Other browsers on OS X „convert“ this file name to NFC.
Here are some related chrome issues:
https://code.google.com/p/chromium/issues/detail?id=125271 <https://code.google.com/p/chromium/issues/detail?id=125271>
https://code.google.com/p/chromium/issues/detail?id=341019 <https://code.google.com/p/chromium/issues/detail?id=341019>
In this issues is not specifically mentioned that this also occurs when uploading files via the Chrome Pepper player.
Maybe, it’s not a bug it’s a feature. ;-)
It seems that NFC is the most used normalization worldwide and it’s recommended to use NFC.
http://unicode.org/faq/normalization.html <http://unicode.org/faq/normalization.html>
http://www.macchiato.com/unicode/nfc-faq <http://www.macchiato.com/unicode/nfc-faq>
To change the NFD file-name (of my uploaded file on OS X on a Mac) to NFC I use:
https://github.com/rozd/as3-unicode-normalizer <https://github.com/rozd/as3-unicode-normalizer>
So, everybody who is using FileReference (uploading files) should be aware of this.
Even if you are on Windows and maybe the users of your Flex app are on on Mac.
This case maybe should be mentioned in the FileReference / FileReferenceList docs.
Thanks.
Greetings
Marcus
> Am 03.11.2015 um 19:01 schrieb Alex Harui <ah...@adobe.com>:
>
> Oh, I forgot to add that one reason to send the 776 to the server and ask
> for the corrected filename is because I think you may find an existing
> PunyCode library for Java that would do the mapping.
>
> On 11/3/15, 9:59 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>> On 11/3/15, 9:43 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>>
>>> Thanks for the advice. It’s maybe the quickest fix to create a
>>> ActionScript function that fixes the file name of any selected file
>>> before I upload a file to the server.
>>>
>>> But seems to be a lot of work, to fix all the allowed UFT-8 characters
>>> which are allowed in file names.
>>
>> I only did enough digging to find the two links. I don’t know if it is
>> better to fix the file names before upload, or ask the server for a
>> corrected file name before displaying it to the user. There might be
>> existing code that will fix the UTF-8 in browsers or in JavaScript that
>> you could call via ExternalInterface. There might be an ActionScript
>> conversion. Or you might be able to get away with a simple test for the
>> 776 character and have a table of replacements.
>>
>>>
>>> Please, correct me if I am wrong, but this is a Google Chrome issue,
>>> right? Should I file a issue for Chrome?
>>
>> There might be more than one issue here. IMO, Flash should properly
>> display the string with the 776 character. I’d be surprised if there
>> isn’t already an issue filed against Chrome, but I would expect their
>> answer to be that they are doing the “right” thing. I’m not an expert in
>> this stuff, but it isn’t clear to me that it is “wrong” to not use 228 in
>> a UTF-8 app, especially if there are algorithms out there that do
>> sorting/collation based on breaking out the diacritics, or for making
>> valid URLs.
>>
>> Good luck,
>> -Alex
>>
>
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Alex Harui <ah...@adobe.com>.
Oh, I forgot to add that one reason to send the 776 to the server and ask
for the corrected filename is because I think you may find an existing
PunyCode library for Java that would do the mapping.
On 11/3/15, 9:59 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 11/3/15, 9:43 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>
>>Thanks for the advice. It’s maybe the quickest fix to create a
>>ActionScript function that fixes the file name of any selected file
>>before I upload a file to the server.
>>
>>But seems to be a lot of work, to fix all the allowed UFT-8 characters
>>which are allowed in file names.
>
>I only did enough digging to find the two links. I don’t know if it is
>better to fix the file names before upload, or ask the server for a
>corrected file name before displaying it to the user. There might be
>existing code that will fix the UTF-8 in browsers or in JavaScript that
>you could call via ExternalInterface. There might be an ActionScript
>conversion. Or you might be able to get away with a simple test for the
>776 character and have a table of replacements.
>
>>
>>Please, correct me if I am wrong, but this is a Google Chrome issue,
>>right? Should I file a issue for Chrome?
>
>There might be more than one issue here. IMO, Flash should properly
>display the string with the 776 character. I’d be surprised if there
>isn’t already an issue filed against Chrome, but I would expect their
>answer to be that they are doing the “right” thing. I’m not an expert in
>this stuff, but it isn’t clear to me that it is “wrong” to not use 228 in
>a UTF-8 app, especially if there are algorithms out there that do
>sorting/collation based on breaking out the diacritics, or for making
>valid URLs.
>
>Good luck,
>-Alex
>
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Alex Harui <ah...@adobe.com>.
On 11/3/15, 9:43 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>Thanks for the advice. It’s maybe the quickest fix to create a
>ActionScript function that fixes the file name of any selected file
>before I upload a file to the server.
>
>But seems to be a lot of work, to fix all the allowed UFT-8 characters
>which are allowed in file names.
I only did enough digging to find the two links. I don’t know if it is
better to fix the file names before upload, or ask the server for a
corrected file name before displaying it to the user. There might be
existing code that will fix the UTF-8 in browsers or in JavaScript that
you could call via ExternalInterface. There might be an ActionScript
conversion. Or you might be able to get away with a simple test for the
776 character and have a table of replacements.
>
>Please, correct me if I am wrong, but this is a Google Chrome issue,
>right? Should I file a issue for Chrome?
There might be more than one issue here. IMO, Flash should properly
display the string with the 776 character. I’d be surprised if there
isn’t already an issue filed against Chrome, but I would expect their
answer to be that they are doing the “right” thing. I’m not an expert in
this stuff, but it isn’t clear to me that it is “wrong” to not use 228 in
a UTF-8 app, especially if there are algorithms out there that do
sorting/collation based on breaking out the diacritics, or for making
valid URLs.
Good luck,
-Alex
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Marcus Fritze <ma...@googlemail.com>.
Thanks for the advice. It’s maybe the quickest fix to create a ActionScript function that fixes the file name of any selected file before I upload a file to the server.
But seems to be a lot of work, to fix all the allowed UFT-8 characters which are allowed in file names.
Please, correct me if I am wrong, but this is a Google Chrome issue, right? Should I file a issue for Chrome?
> Am 03.11.2015 um 17:59 schrieb Alex Harui <ah...@adobe.com>:
>
> Yeah, so you might just have to try to detect this condition.
>
> Here’s another link: http://superuser.com/questions/896426/chrome-copy-paste-of-url-with-german-umlaut-changes-characters
>
> -Alex
>
> From: Marcus Fritze <ma...@googlemail.com>>
> Reply-To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
> Date: Tuesday, November 3, 2015 at 9:21 AM
> To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
> Subject: Re: serious problem with FileReferenceList in Chrome on Mac
>
> Safari does the same as Firefox (is working):
>
> selected file name: ABC_ä.png
>
> charcode at 0 = 65 is char A
> charcode at 1 = 66 is char B
> charcode at 2 = 67 is char C
> charcode at 3 = 95 is char _
> charcode at 4 = 228 is char ä
> charcode at 5 = 46 is char .
> charcode at 6 = 112 is char p
> charcode at 7 = 110 is char n
> charcode at 8 = 103 is char g
>
>
> Am 03.11.2015 um 17:06 schrieb Alex Harui <ah...@adobe.com>>:
>
> I did some digging, and the implication of this article is that Firefox is not handling UTF-8 in the file names, although as pointed out in the article [1], Chrome’s handling breaks web sites. What does Safari do?
>
> -Alex
>
> [1] http://stackoverflow.com/questions/9975149/difference-firefox-chrome-when-encoding-umlauts
>
> From: Marcus Fritze <ma...@googlemail.com>>
> Reply-To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
> Date: Tuesday, November 3, 2015 at 5:44 AM
> To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
> Subject: Re: serious problem with FileReferenceList in Chrome on Mac
>
> Thank you very much for the useful tips.
>
> Ok, when I select the file name
>
> ABC_ä.png
>
> result in Firefox on a Mac:
>
> selected file name: ABC_ä.png
>
>
> charcode at 0 = 65 is char A
> charcode at 1 = 66 is char B
> charcode at 2 = 67 is char C
> charcode at 3 = 95 is char _
> charcode at 4 = 228 is char ä
> charcode at 5 = 46 is char .
> charcode at 6 = 112 is char p
> charcode at 7 = 110 is char n
> charcode at 8 = 103 is char g
>
> result in Chrome on Mac:
>
> selected file name: ABC_ä.png
>
> charcode at 0 = 65 is char A
> charcode at 1 = 66 is char B
> charcode at 2 = 67 is char C
> charcode at 3 = 95 is char _
> charcode at 4 = 97 is char a
> charcode at 5 = 776 is char ̈
> charcode at 6 = 46 is char .
> charcode at 7 = 112 is char p
> charcode at 8 = 110 is char n
> charcode at 9 = 103 is char g
>
>
> So the ä is in Firefox 228 (which is actually the correct code), but the ä is in Chrome on a Mac 97 (code for the character a) and 776 (code for the 2 dots over the a).
>
> This issue occurs even when I don’t embed any font in my app.
>
> So how can I solve this? Can I even solve this myself? Maybe it’s a Pepper Player issue.
>
> Here is my test-code:
>
> <?xml version="1.0" encoding="utf-8"?>
> <s:Application
> xmlns:fx="http://ns.adobe.com/mxml/2009"
> xmlns:s="library://ns.adobe.com/flex/spark"
> xmlns:mx="library://ns.adobe.com/flex/mx">
>
>
> <fx:Script>
> <![CDATA[
> import mx.controls.Alert;
>
>
> private var _refAddFiles:FileReferenceList;
>
>
> private function uploadTest():void
> {
> _refAddFiles = new FileReferenceList();
> _refAddFiles.addEventListener(Event.SELECT, onSelectFileRef);
> _refAddFiles.browse();
> }
>
>
> private function onSelectFileRef(event:Event):void
> {
> for each(var uploadFile:Object in _refAddFiles.fileList)
> {
> var dateiName:String = uploadFile.name;
>
>
> trace("selected file name: " + dateiName);
>
>
> var traceAlert:String = "selected file name: " + dateiName + "\n\n";
>
>
> for(var i:int = 0; i < dateiName.length; i++)
> {
> var traceStr:String = "charcode at " + i + " = " + dateiName.charCodeAt(i) + " is char " + String.fromCharCode(dateiName.charCodeAt(i));
>
>
> traceAlert += "\n" + traceStr;
>
>
> trace(traceStr);
> }
>
>
> Alert.show(traceAlert);
> }
> }
>
>
> ]]>
> </fx:Script>
>
>
> <s:Button label="upload test" click="{uploadTest()}"/>
>
>
> </s:Application>
>
>
>
> Am 02.11.2015 um 17:52 schrieb Alex Harui <ah...@adobe.com>>:
>
> Try dumping the charCode for each character in the file name. I wonder if
> you having some sort of double-byte or code page issue.
>
> -Alex
>
> On 11/2/15, 8:35 AM, "Marcus Fritze" <ma...@googlemail.com>> wrote:
>
> Mhm, the font is Verdana. So nothing special.
>
> But, when I set the fileRef.name to a TextField the file-name Test_ä.pdf
> is shown as Test_a.pdf
>
> And when I move the cursor after the „a" in the TextField and press
> backspace, the invisible
> character will be deleted, when I press backspace again, the „a“ will be
> deleted.
>
> But is my embedded font used when I save the file-name internally and
> upload the file-name to the server?
>
> Maybe, I should test on a older OS X (and not the latest version).
>
> Am 02.11.2015 um 17:21 schrieb Tom Chiverton <tc...@extravision.com>>:
>
> On 02/11/15 16:16, Marcus Fritze wrote:
> (where I use embedded font, it works)
>
> Maybe the font doesn't have the correct glyphs.
>
> Tom
>
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Alex Harui <ah...@adobe.com>.
Yeah, so you might just have to try to detect this condition.
Here’s another link: http://superuser.com/questions/896426/chrome-copy-paste-of-url-with-german-umlaut-changes-characters
-Alex
From: Marcus Fritze <ma...@googlemail.com>>
Reply-To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
Date: Tuesday, November 3, 2015 at 9:21 AM
To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
Subject: Re: serious problem with FileReferenceList in Chrome on Mac
Safari does the same as Firefox (is working):
selected file name: ABC_ä.png
charcode at 0 = 65 is char A
charcode at 1 = 66 is char B
charcode at 2 = 67 is char C
charcode at 3 = 95 is char _
charcode at 4 = 228 is char ä
charcode at 5 = 46 is char .
charcode at 6 = 112 is char p
charcode at 7 = 110 is char n
charcode at 8 = 103 is char g
Am 03.11.2015 um 17:06 schrieb Alex Harui <ah...@adobe.com>>:
I did some digging, and the implication of this article is that Firefox is not handling UTF-8 in the file names, although as pointed out in the article [1], Chrome’s handling breaks web sites. What does Safari do?
-Alex
[1] http://stackoverflow.com/questions/9975149/difference-firefox-chrome-when-encoding-umlauts
From: Marcus Fritze <ma...@googlemail.com>>
Reply-To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
Date: Tuesday, November 3, 2015 at 5:44 AM
To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
Subject: Re: serious problem with FileReferenceList in Chrome on Mac
Thank you very much for the useful tips.
Ok, when I select the file name
ABC_ä.png
result in Firefox on a Mac:
selected file name: ABC_ä.png
charcode at 0 = 65 is char A
charcode at 1 = 66 is char B
charcode at 2 = 67 is char C
charcode at 3 = 95 is char _
charcode at 4 = 228 is char ä
charcode at 5 = 46 is char .
charcode at 6 = 112 is char p
charcode at 7 = 110 is char n
charcode at 8 = 103 is char g
result in Chrome on Mac:
selected file name: ABC_ä.png
charcode at 0 = 65 is char A
charcode at 1 = 66 is char B
charcode at 2 = 67 is char C
charcode at 3 = 95 is char _
charcode at 4 = 97 is char a
charcode at 5 = 776 is char ̈
charcode at 6 = 46 is char .
charcode at 7 = 112 is char p
charcode at 8 = 110 is char n
charcode at 9 = 103 is char g
So the ä is in Firefox 228 (which is actually the correct code), but the ä is in Chrome on a Mac 97 (code for the character a) and 776 (code for the 2 dots over the a).
This issue occurs even when I don’t embed any font in my app.
So how can I solve this? Can I even solve this myself? Maybe it’s a Pepper Player issue.
Here is my test-code:
<?xml version="1.0" encoding="utf-8"?>
<s:Application
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
<fx:Script>
<![CDATA[
import mx.controls.Alert;
private var _refAddFiles:FileReferenceList;
private function uploadTest():void
{
_refAddFiles = new FileReferenceList();
_refAddFiles.addEventListener(Event.SELECT, onSelectFileRef);
_refAddFiles.browse();
}
private function onSelectFileRef(event:Event):void
{
for each(var uploadFile:Object in _refAddFiles.fileList)
{
var dateiName:String = uploadFile.name;
trace("selected file name: " + dateiName);
var traceAlert:String = "selected file name: " + dateiName + "\n\n";
for(var i:int = 0; i < dateiName.length; i++)
{
var traceStr:String = "charcode at " + i + " = " + dateiName.charCodeAt(i) + " is char " + String.fromCharCode(dateiName.charCodeAt(i));
traceAlert += "\n" + traceStr;
trace(traceStr);
}
Alert.show(traceAlert);
}
}
]]>
</fx:Script>
<s:Button label="upload test" click="{uploadTest()}"/>
</s:Application>
Am 02.11.2015 um 17:52 schrieb Alex Harui <ah...@adobe.com>>:
Try dumping the charCode for each character in the file name. I wonder if
you having some sort of double-byte or code page issue.
-Alex
On 11/2/15, 8:35 AM, "Marcus Fritze" <ma...@googlemail.com>> wrote:
Mhm, the font is Verdana. So nothing special.
But, when I set the fileRef.name to a TextField the file-name Test_ä.pdf
is shown as Test_a.pdf
And when I move the cursor after the „a" in the TextField and press
backspace, the invisible
character will be deleted, when I press backspace again, the „a“ will be
deleted.
But is my embedded font used when I save the file-name internally and
upload the file-name to the server?
Maybe, I should test on a older OS X (and not the latest version).
Am 02.11.2015 um 17:21 schrieb Tom Chiverton <tc...@extravision.com>>:
On 02/11/15 16:16, Marcus Fritze wrote:
(where I use embedded font, it works)
Maybe the font doesn't have the correct glyphs.
Tom
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Marcus Fritze <ma...@googlemail.com>.
Safari does the same as Firefox (is working):
selected file name: ABC_ä.png
charcode at 0 = 65 is char A
charcode at 1 = 66 is char B
charcode at 2 = 67 is char C
charcode at 3 = 95 is char _
charcode at 4 = 228 is char ä
charcode at 5 = 46 is char .
charcode at 6 = 112 is char p
charcode at 7 = 110 is char n
charcode at 8 = 103 is char g
> Am 03.11.2015 um 17:06 schrieb Alex Harui <ah...@adobe.com>:
>
> I did some digging, and the implication of this article is that Firefox is not handling UTF-8 in the file names, although as pointed out in the article [1], Chrome’s handling breaks web sites. What does Safari do?
>
> -Alex
>
> [1] http://stackoverflow.com/questions/9975149/difference-firefox-chrome-when-encoding-umlauts <http://stackoverflow.com/questions/9975149/difference-firefox-chrome-when-encoding-umlauts>
>
> From: Marcus Fritze <marcus.fritze@googlemail.com <ma...@googlemail.com><mailto:marcus.fritze@googlemail.com <ma...@googlemail.com>>>
> Reply-To: "users@flex.apache.org <ma...@flex.apache.org><mailto:users@flex.apache.org <ma...@flex.apache.org>>" <users@flex.apache.org <ma...@flex.apache.org><mailto:users@flex.apache.org <ma...@flex.apache.org>>>
> Date: Tuesday, November 3, 2015 at 5:44 AM
> To: "users@flex.apache.org <ma...@flex.apache.org><mailto:users@flex.apache.org <ma...@flex.apache.org>>" <users@flex.apache.org <ma...@flex.apache.org><mailto:users@flex.apache.org <ma...@flex.apache.org>>>
> Subject: Re: serious problem with FileReferenceList in Chrome on Mac
>
> Thank you very much for the useful tips.
>
> Ok, when I select the file name
>
> ABC_ä.png
>
> result in Firefox on a Mac:
>
> selected file name: ABC_ä.png
>
>
> charcode at 0 = 65 is char A
> charcode at 1 = 66 is char B
> charcode at 2 = 67 is char C
> charcode at 3 = 95 is char _
> charcode at 4 = 228 is char ä
> charcode at 5 = 46 is char .
> charcode at 6 = 112 is char p
> charcode at 7 = 110 is char n
> charcode at 8 = 103 is char g
>
> result in Chrome on Mac:
>
> selected file name: ABC_ä.png
>
> charcode at 0 = 65 is char A
> charcode at 1 = 66 is char B
> charcode at 2 = 67 is char C
> charcode at 3 = 95 is char _
> charcode at 4 = 97 is char a
> charcode at 5 = 776 is char ̈
> charcode at 6 = 46 is char .
> charcode at 7 = 112 is char p
> charcode at 8 = 110 is char n
> charcode at 9 = 103 is char g
>
>
> So the ä is in Firefox 228 (which is actually the correct code), but the ä is in Chrome on a Mac 97 (code for the character a) and 776 (code for the 2 dots over the a).
>
> This issue occurs even when I don’t embed any font in my app.
>
> So how can I solve this? Can I even solve this myself? Maybe it’s a Pepper Player issue.
>
> Here is my test-code:
>
> <?xml version="1.0" encoding="utf-8"?>
> <s:Application
> xmlns:fx="http://ns.adobe.com/mxml/2009"
> xmlns:s="library://ns.adobe.com/flex/spark"
> xmlns:mx="library://ns.adobe.com/flex/mx">
>
>
> <fx:Script>
> <![CDATA[
> import mx.controls.Alert;
>
>
> private var _refAddFiles:FileReferenceList;
>
>
> private function uploadTest():void
> {
> _refAddFiles = new FileReferenceList();
> _refAddFiles.addEventListener(Event.SELECT, onSelectFileRef);
> _refAddFiles.browse();
> }
>
>
> private function onSelectFileRef(event:Event):void
> {
> for each(var uploadFile:Object in _refAddFiles.fileList)
> {
> var dateiName:String = uploadFile.name;
>
>
> trace("selected file name: " + dateiName);
>
>
> var traceAlert:String = "selected file name: " + dateiName + "\n\n";
>
>
> for(var i:int = 0; i < dateiName.length; i++)
> {
> var traceStr:String = "charcode at " + i + " = " + dateiName.charCodeAt(i) + " is char " + String.fromCharCode(dateiName.charCodeAt(i));
>
>
> traceAlert += "\n" + traceStr;
>
>
> trace(traceStr);
> }
>
>
> Alert.show(traceAlert);
> }
> }
>
>
> ]]>
> </fx:Script>
>
>
> <s:Button label="upload test" click="{uploadTest()}"/>
>
>
> </s:Application>
>
>
>
> Am 02.11.2015 um 17:52 schrieb Alex Harui <aharui@adobe.com <ma...@adobe.com><mailto:aharui@adobe.com <ma...@adobe.com>>>:
>
> Try dumping the charCode for each character in the file name. I wonder if
> you having some sort of double-byte or code page issue.
>
> -Alex
>
> On 11/2/15, 8:35 AM, "Marcus Fritze" <marcus.fritze@googlemail.com <ma...@googlemail.com><mailto:marcus.fritze@googlemail.com <ma...@googlemail.com>>> wrote:
>
> Mhm, the font is Verdana. So nothing special.
>
> But, when I set the fileRef.name to a TextField the file-name Test_ä.pdf
> is shown as Test_a.pdf
>
> And when I move the cursor after the „a" in the TextField and press
> backspace, the invisible
> character will be deleted, when I press backspace again, the „a“ will be
> deleted.
>
> But is my embedded font used when I save the file-name internally and
> upload the file-name to the server?
>
> Maybe, I should test on a older OS X (and not the latest version).
>
> Am 02.11.2015 um 17:21 schrieb Tom Chiverton <tc@extravision.com <ma...@extravision.com><mailto:tc@extravision.com <ma...@extravision.com>>>:
>
> On 02/11/15 16:16, Marcus Fritze wrote:
> (where I use embedded font, it works)
>
> Maybe the font doesn't have the correct glyphs.
>
> Tom
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Alex Harui <ah...@adobe.com>.
I did some digging, and the implication of this article is that Firefox is not handling UTF-8 in the file names, although as pointed out in the article [1], Chrome’s handling breaks web sites. What does Safari do?
-Alex
[1] http://stackoverflow.com/questions/9975149/difference-firefox-chrome-when-encoding-umlauts
From: Marcus Fritze <ma...@googlemail.com>>
Reply-To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
Date: Tuesday, November 3, 2015 at 5:44 AM
To: "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>
Subject: Re: serious problem with FileReferenceList in Chrome on Mac
Thank you very much for the useful tips.
Ok, when I select the file name
ABC_ä.png
result in Firefox on a Mac:
selected file name: ABC_ä.png
charcode at 0 = 65 is char A
charcode at 1 = 66 is char B
charcode at 2 = 67 is char C
charcode at 3 = 95 is char _
charcode at 4 = 228 is char ä
charcode at 5 = 46 is char .
charcode at 6 = 112 is char p
charcode at 7 = 110 is char n
charcode at 8 = 103 is char g
result in Chrome on Mac:
selected file name: ABC_ä.png
charcode at 0 = 65 is char A
charcode at 1 = 66 is char B
charcode at 2 = 67 is char C
charcode at 3 = 95 is char _
charcode at 4 = 97 is char a
charcode at 5 = 776 is char ̈
charcode at 6 = 46 is char .
charcode at 7 = 112 is char p
charcode at 8 = 110 is char n
charcode at 9 = 103 is char g
So the ä is in Firefox 228 (which is actually the correct code), but the ä is in Chrome on a Mac 97 (code for the character a) and 776 (code for the 2 dots over the a).
This issue occurs even when I don’t embed any font in my app.
So how can I solve this? Can I even solve this myself? Maybe it’s a Pepper Player issue.
Here is my test-code:
<?xml version="1.0" encoding="utf-8"?>
<s:Application
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
<fx:Script>
<![CDATA[
import mx.controls.Alert;
private var _refAddFiles:FileReferenceList;
private function uploadTest():void
{
_refAddFiles = new FileReferenceList();
_refAddFiles.addEventListener(Event.SELECT, onSelectFileRef);
_refAddFiles.browse();
}
private function onSelectFileRef(event:Event):void
{
for each(var uploadFile:Object in _refAddFiles.fileList)
{
var dateiName:String = uploadFile.name;
trace("selected file name: " + dateiName);
var traceAlert:String = "selected file name: " + dateiName + "\n\n";
for(var i:int = 0; i < dateiName.length; i++)
{
var traceStr:String = "charcode at " + i + " = " + dateiName.charCodeAt(i) + " is char " + String.fromCharCode(dateiName.charCodeAt(i));
traceAlert += "\n" + traceStr;
trace(traceStr);
}
Alert.show(traceAlert);
}
}
]]>
</fx:Script>
<s:Button label="upload test" click="{uploadTest()}"/>
</s:Application>
Am 02.11.2015 um 17:52 schrieb Alex Harui <ah...@adobe.com>>:
Try dumping the charCode for each character in the file name. I wonder if
you having some sort of double-byte or code page issue.
-Alex
On 11/2/15, 8:35 AM, "Marcus Fritze" <ma...@googlemail.com>> wrote:
Mhm, the font is Verdana. So nothing special.
But, when I set the fileRef.name to a TextField the file-name Test_ä.pdf
is shown as Test_a.pdf
And when I move the cursor after the „a" in the TextField and press
backspace, the invisible
character will be deleted, when I press backspace again, the „a“ will be
deleted.
But is my embedded font used when I save the file-name internally and
upload the file-name to the server?
Maybe, I should test on a older OS X (and not the latest version).
Am 02.11.2015 um 17:21 schrieb Tom Chiverton <tc...@extravision.com>>:
On 02/11/15 16:16, Marcus Fritze wrote:
(where I use embedded font, it works)
Maybe the font doesn't have the correct glyphs.
Tom
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Marcus Fritze <ma...@googlemail.com>.
Thank you very much for the useful tips.
Ok, when I select the file name
ABC_ä.png
result in Firefox on a Mac:
selected file name: ABC_ä.png
charcode at 0 = 65 is char A
charcode at 1 = 66 is char B
charcode at 2 = 67 is char C
charcode at 3 = 95 is char _
charcode at 4 = 228 is char ä
charcode at 5 = 46 is char .
charcode at 6 = 112 is char p
charcode at 7 = 110 is char n
charcode at 8 = 103 is char g
result in Chrome on Mac:
selected file name: ABC_ä.png
charcode at 0 = 65 is char A
charcode at 1 = 66 is char B
charcode at 2 = 67 is char C
charcode at 3 = 95 is char _
charcode at 4 = 97 is char a
charcode at 5 = 776 is char ̈
charcode at 6 = 46 is char .
charcode at 7 = 112 is char p
charcode at 8 = 110 is char n
charcode at 9 = 103 is char g
So the ä is in Firefox 228 (which is actually the correct code), but the ä is in Chrome on a Mac 97 (code for the character a) and 776 (code for the 2 dots over the a).
This issue occurs even when I don’t embed any font in my app.
So how can I solve this? Can I even solve this myself? Maybe it’s a Pepper Player issue.
Here is my test-code:
<?xml version="1.0" encoding="utf-8"?>
<s:Application
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
<fx:Script>
<![CDATA[
import mx.controls.Alert;
private var _refAddFiles:FileReferenceList;
private function uploadTest():void
{
_refAddFiles = new FileReferenceList();
_refAddFiles.addEventListener(Event.SELECT, onSelectFileRef);
_refAddFiles.browse();
}
private function onSelectFileRef(event:Event):void
{
for each(var uploadFile:Object in _refAddFiles.fileList)
{
var dateiName:String = uploadFile.name;
trace("selected file name: " + dateiName);
var traceAlert:String = "selected file name: " + dateiName + "\n\n";
for(var i:int = 0; i < dateiName.length; i++)
{
var traceStr:String = "charcode at " + i + " = " + dateiName.charCodeAt(i) + " is char " + String.fromCharCode(dateiName.charCodeAt(i));
traceAlert += "\n" + traceStr;
trace(traceStr);
}
Alert.show(traceAlert);
}
}
]]>
</fx:Script>
<s:Button label="upload test" click="{uploadTest()}"/>
</s:Application>
> Am 02.11.2015 um 17:52 schrieb Alex Harui <ah...@adobe.com>:
>
> Try dumping the charCode for each character in the file name. I wonder if
> you having some sort of double-byte or code page issue.
>
> -Alex
>
> On 11/2/15, 8:35 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>
>> Mhm, the font is Verdana. So nothing special.
>>
>> But, when I set the fileRef.name to a TextField the file-name Test_ä.pdf
>> is shown as Test_a.pdf
>>
>> And when I move the cursor after the „a" in the TextField and press
>> backspace, the invisible
>> character will be deleted, when I press backspace again, the „a“ will be
>> deleted.
>>
>> But is my embedded font used when I save the file-name internally and
>> upload the file-name to the server?
>>
>> Maybe, I should test on a older OS X (and not the latest version).
>>
>>> Am 02.11.2015 um 17:21 schrieb Tom Chiverton <tc...@extravision.com>:
>>>
>>> On 02/11/15 16:16, Marcus Fritze wrote:
>>>> (where I use embedded font, it works)
>>>
>>> Maybe the font doesn't have the correct glyphs.
>>>
>>> Tom
>>
>
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Alex Harui <ah...@adobe.com>.
Try dumping the charCode for each character in the file name. I wonder if
you having some sort of double-byte or code page issue.
-Alex
On 11/2/15, 8:35 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>Mhm, the font is Verdana. So nothing special.
>
>But, when I set the fileRef.name to a TextField the file-name Test_ä.pdf
>is shown as Test_a.pdf
>
>And when I move the cursor after the „a" in the TextField and press
>backspace, the invisible
>character will be deleted, when I press backspace again, the „a“ will be
>deleted.
>
>But is my embedded font used when I save the file-name internally and
>upload the file-name to the server?
>
>Maybe, I should test on a older OS X (and not the latest version).
>
>> Am 02.11.2015 um 17:21 schrieb Tom Chiverton <tc...@extravision.com>:
>>
>> On 02/11/15 16:16, Marcus Fritze wrote:
>>> (where I use embedded font, it works)
>>
>> Maybe the font doesn't have the correct glyphs.
>>
>> Tom
>
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Marcus Fritze <ma...@googlemail.com>.
Mhm, the font is Verdana. So nothing special.
But, when I set the fileRef.name to a TextField the file-name Test_ä.pdf is shown as Test_a.pdf
And when I move the cursor after the „a" in the TextField and press backspace, the invisible
character will be deleted, when I press backspace again, the „a“ will be deleted.
But is my embedded font used when I save the file-name internally and upload the file-name to the server?
Maybe, I should test on a older OS X (and not the latest version).
> Am 02.11.2015 um 17:21 schrieb Tom Chiverton <tc...@extravision.com>:
>
> On 02/11/15 16:16, Marcus Fritze wrote:
>> (where I use embedded font, it works)
>
> Maybe the font doesn't have the correct glyphs.
>
> Tom
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Tom Chiverton <tc...@extravision.com>.
On 02/11/15 16:16, Marcus Fritze wrote:
> (where I use embedded font, it works)
Maybe the font doesn't have the correct glyphs.
Tom
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Marcus Fritze <ma...@googlemail.com>.
Thanks for the advice, but the name is already incorrect in my onSelectFunction ( after .browse() ).
For debugging, I currently make Alert.show(fileRef.name).
here is my code:
private var _refAddFiles:FileReferenceList;
private function uploadTest2():void
{
_refAddFiles = new FileReferenceList();
_refAddFiles.addEventListener(Event.SELECT, onSelectFileRef);
_refAddFiles.browse();
}
private function onSelectFileRef(event:Event):void
{
for each(var uploadFile:Object in _refAddFiles.fileList)
{
trace("selected file name: " + uploadFile.name);
Alert.show("selected file name: " + uploadFile.name);
}
}
And the name in the Alert is without umlauts and incorrect. But only chrome on a mac, other browsers are working.
I still try to find the error. It’s even harder to find, because the flash debugger doesn’t work for me on chrome (mac):
https://code.google.com/p/chromium/issues/detail?id=478056 <https://code.google.com/p/chromium/issues/detail?id=478056>
I try to comment-out all the other source-code in my project to find the issue. Actually, when I comment-out some css
(where I use embedded font, it works). I have no idea why. I have to debug a little bit more.
Btw, how do other people debug flash with Chrome on a Mac? Is it still possible?
Thanks.
> Am 02.11.2015 um 16:53 schrieb Alex Harui <ah...@adobe.com>:
>
>
>
> On 11/2/15, 2:13 AM, "Marcus Fritze" <marcus.fritze@googlemail.com <ma...@googlemail.com>> wrote:
>
>> Hi,
>>
>> actually I have a serious problem with FileReferenceList in Google Chrome
>> on (every) Mac.
>>
>> When I try to upload files with FileReferenceList in my flex application,
>> the file names are not correct. Umlauts (ä, ö, ü) and other special
>> characters (å) are not correctly „parsed“.
>>
>> For example, when I upload
>>
>> Test_äöü.pdf
>>
>> my flex application recognizes the file name
>>
>> Test_aou.pdf
>>
>> So, when I create a new test-project, were I use FileReferenceList and
>> try to test this issue, this error doesn’t occur. So I think it must be
>> related to my generated project. I have no idea, what I can do.
>>
>> Any help?
>
> I think you can use a network monitor to see what is sent. Maybe that
> will help you determine when the umlauts are stripped off.
>
> HTH,
> -Alex
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Alex Harui <ah...@adobe.com>.
On 11/2/15, 2:13 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>Hi,
>
>actually I have a serious problem with FileReferenceList in Google Chrome
>on (every) Mac.
>
>When I try to upload files with FileReferenceList in my flex application,
>the file names are not correct. Umlauts (ä, ö, ü) and other special
>characters (å) are not correctly „parsed“.
>
>For example, when I upload
>
>Test_äöü.pdf
>
>my flex application recognizes the file name
>
>Test_aou.pdf
>
>So, when I create a new test-project, were I use FileReferenceList and
>try to test this issue, this error doesn’t occur. So I think it must be
>related to my generated project. I have no idea, what I can do.
>
>Any help?
I think you can use a network monitor to see what is sent. Maybe that
will help you determine when the umlauts are stripped off.
HTH,
-Alex
Re: serious problem with FileReferenceList in Chrome on Mac
Posted by Hans Nuecke <hn...@vservu.de>.
Hi Marcus,
although it sounds like some weird behavior that I did not experience
yet (I'm not working in a Browser but in AIR on Desktop or Mobile), I
wanted to share some links that helped me solving the "special
character" problem.
I found these links helpful:
http://xkr.us/articles/javascript/encode-compare/
<http://xkr.us/articles/javascript/encode-compare/>
http://stackoverflow.com/questions/1929812/how-does-cut-and-paste-affect-character-encoding-and-what-can-go-wrong
http://www.zehnet.de/2005/02/12/unicode-utf-8-tutorial/
<http://www.zehnet.de/2005/02/12/unicode-utf-8-tutorial/>
http://stackoverflow.com/questions/5552277/when-to-use-writeutf-and-writeutfbytes-in-bytearray-of-as3
http://stackoverflow.com/questions/75980/best-practice-escape-or-encodeuri-encodeuricomponent
https://sunilanair.wordpress.com/2009/08/08/encoding-decoding-functions-in-flex/
Hopefully you'll get some more ideas or suggestions what you could try.
Good luck!
Regards
Hans
Am 02.11.2015 um 11:13 schrieb Marcus Fritze:
> Hi,
>
> actually I have a serious problem with FileReferenceList in Google Chrome on (every) Mac.
>
> When I try to upload files with FileReferenceList in my flex application, the file names are not correct. Umlauts (ä, ö, ü) and other special characters (å) are not correctly „parsed“.
>
> For example, when I upload
>
> Test_äöü.pdf
>
> my flex application recognizes the file name
>
> Test_aou.pdf
>
> So, when I create a new test-project, were I use FileReferenceList and try to test this issue, this error doesn’t occur. So I think it must be related to my generated project. I have no idea, what I can do.
>
> Any help?
>
> Thanks.
>
> Marcus Fritze