flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: serious problem with FileReferenceList in Chrome on Mac
Date Wed, 11 Nov 2015 16:44:22 GMT
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 <marcus.fritze@googlemail.com<mailto:marcus.fritze@googlemail.com>>
Reply-To: "users@flex.apache.org<mailto:users@flex.apache.org>" <users@flex.apache.org<mailto:users@flex.apache.org>>
Date: Wednesday, November 11, 2015 at 5:50 AM
To: "users@flex.apache.org<mailto:users@flex.apache.org>" <users@flex.apache.org<mailto:users@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 <aharui@adobe.com<mailto:aharui@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" <aharui@adobe.com<mailto:aharui@adobe.com>>
wrote:



On 11/3/15, 9:43 AM, "Marcus Fritze" <marcus.fritze@googlemail.com<mailto:marcus.fritze@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



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message