Problem loading Image data with French accent in file name

Question

We have a very complex commercial application that has been working perfectly in English for over a year. We have now localized it to French and Spanish, and discovered a serious show-stopping problem. We need help fast, with the scheduled release being less than 2 weeks away...!
We iterate over a folder to find all the images in it, then display those in a user window.  The code for loading the images is:
            for each (var name:String in filenames){
                var image:SmoothImageTransformable = new SmoothImageTransformable();
                var imagePath:String = dir + "/" + name;
                image.source = imagePath;
                trace("Adding Item to picture carousel with url " + image.source);
                image.data = {directory:dir, filename:name};
                image.isDragEnabled = true;
                image.setStyle("horizontalCenter", 0);
                image.setStyle("verticalCenter", 0);
                _images.push(image);
Our SmoothImageTransformable class is an internal class that inherits from Image.  This all works fine for image names like 'myFavoritePhoto', 'test', 'photo346', etc.  However, it fails to load the data if the file name is something like 'caméra'  Any name with a UTF-8 character causes the data load to fail.
To be sure we weren't doing a load somewhere else in the code that I had overlooked, I added a "image.autoLoad = false' line in there.  That did exactly as expected -- all image squares then show a grey blank, with no image shown.  Removing that line (reverting to the original code, as shown above) causes all the images to work perfectly, except for those with French accent characters like the é.
HELP!  Is this a known bug?  Is there some additional setting I need to make it understand the extended character set?  I can't find any mention about this at all in the documentation.

Answer 1

@markerline:
We have a fix!  Almost...   I don't understand one aspect of what I am seeing though.
We have one test file named "camèra.jpg" that is an example of what I am unable to load into an Image.  I decided to examine the character codes at each letter, and this is what Flex has as the string:
name = cam?ra.jpg
   [0] = c; 0x99
   [1] = a; 0x97
   [2] = m; 0x109
   [3] = ?; 0x232
   [4] = r; 0x114
   [5] = a; 0x97
   [6] = .; 0x46
   [7] = j; 0x106
   [8] = p; 0x112
   [9] = g; 0x103
Note that the è prints as gibberish in the trace statement, and shows a numeric encoding of 0x232.  According to
     http://docstore.mik.ua/orelly/web2/action/appb_01.htm
The unicode equivalent of Latin1 for è is 0xE8, which is equivalent to 0x232. That implies that the string is already Latin1, which I would think would mean that Windoze would recognize the file name and open it properly -- but it does not.
I then tried taking the "camèra.jpg" string, pasting it into NotePad++ in a UTF8 document, then telling NotePad++ to display as ASCII.  The result is "camèra".  I then tried just forcing the file name within Flex to this new mangled string.  The result then is:
MAGIC name = camèra
   [0] = c; 0x99
   [1] = a; 0x97
   [2] = m; 0x109
   [3] = ?; 0x195
   [4] = ?; 0x168
   [5] = r; 0x114
   [6] = a; 0x97
   [7] = .; 0x46
   [8] = j; 0x106
   [9] = p; 0x112
  [10] = g; 0x103
Note this time the trace statement looks proper.  More important, the IMAGE DOES LOAD!  (Our display of the name to the user now looks like crap, but that just means I need to modify our class to have a separate 'name' property, rather than extracting it from the 'image.source')
So... my remaining question -- what encoding did I just do through that NotePad++ incantation?  That site I quoted above said that it was already Latin1, which is what I thought I was trying to get to.  I clearly need to write a method to map from incoming (UTF8 I thought, but maybe Latin1?) to Windows file system (Latin1 I thought, but maybe ASCII).
In other words, I am not sure what charcter set to come from or go to...  It turns out the code was already in the character set I had been trying to go to (which is why it wasn't working) and the set I seem to need to go to is not the one I thought...