International characters in filenames on FAT32

Hi folks,
I have recently replaced nearly all the computers in my home office with a spiffy new iMac dual-booted to Windows Vista with Linux sitting in a Parallels space. In the course of doing this, I purchased two external WD 500 Gb drives, which are currently formatted FAT32. One drive holds everything I would actually lose if I had to reinstall my system - my own creations, all the CDs from my collection that I don't ever want to go through ripping again, etc., and the other drive holds a backup of the first drive.
Here's my problem. I saved away all my MP3s and such on the external FAT32 drive, writing them from the Windows side of the boot. None of these are really big files so there is no big deal. On the Mac side, I can access nearly everything except any file or folder that has characters in the name like ü or é. This limits my access to anything by Motörhead or Mötley Crüe, not to mention all my hacienda music and Finnish folk metal. (My wife, of course, doesn't see a problem in this at all. )
The actual behavior is kind of strange. Finder shows the Motörhead folder name in the parent folder but doesn't recognize that it is a folder. If I do a Get Info on it, it disappears from the parent folder unless I collapse and uncollapse the parent folder - then it shows up again. A file like Corazón.mp3 from Carole King's Greatest Hits (ah, now my wife would like this solved ) shows up as a 0 kb alias. If I double-click it, I get an error -43.
All of these files and folders display and perform flawlessly from my Vista boot. Does anybody know why this is happening with the FAT32 driver on the Mac side or what can be done about it? Is there some tweak or parameter that can be fed to the driver to help it to behave? Interestingly, it is very similar to behavior I have seen before accessing similar files from Windows shares, which is why I was using an NFS mount rather than a Samba share to provide these files to the Mac from my Linux box before the consolidation. How would I submit a ticket to have this behavior corrected in a future release or patch?
At least for now, I can't see much I can do except to go over to the Windows side and rename each of the files and directories involved to use only unaccented characters and then carefully doctor my iTunes properties where necessary to use the right letters rather than the (bastardized) ones from the file names. I'd rather not take that route as it involves 7 album titles, a few band names, and a couple dozen songs. (Yes, I went through my 6300 songs and made a comprehensive list - clearly I must have no life )

Stefan,
It's good news that you are not having this problem, as it means that perhaps I won't shortly either. If we can characterize the differences between our setups, maybe I can have the same result as you do.
I've just run the obvious case - I've created a file using TextEdit with a German name out on the volume from the Mac, stopped TextEdit, and successfully retrieved it. So it doesn't look like a filesystem mounting issue. I wonder what is so weird about these files. There must be something odd in the header, because it is definitely at the file info level that it is going off the rails. While the name is the obvious differentiator, maybe something else is odd as well.
One thing I could try is to zip one of the directories affected on the Windows side and then try unzipping it into place there, then boot over to the Mac side and see if things have improved. If that doesn't resolve the problem, I could try unzipping it into place on the Mac side, but first I'll boot over to the Windows side and make sure it can read the file I just created in TextEdit from that end.
By the way, the KB article you referenced was about shares and about problems with punctuation mounting Mac shares on Windows, so I don't think it pertains. In any case, I'm mounting a FAT volume, not a share, so the drivers would be completely different.
Anyway, thank you for your help. Now that I'm no longer chasing phantoms, I can attend the real problem.
Thanks,
Ralph

Similar Messages

International characters in IOS filenames

Hello,
My movie compiles fine but when I add this file name to the package:
ahí1.wav
I get an applicationverificationfailed message when I try to send it to the device from flash cc
if I rename it to:
ahi1.wav
It will work without failure.
I've got hundreds of files that have international characters do I have to rename them all or is there a special flag, switch, or trick I can use to get around this?

Stefan,
It's good news that you are not having this problem, as it means that perhaps I won't shortly either. If we can characterize the differences between our setups, maybe I can have the same result as you do.
I've just run the obvious case - I've created a file using TextEdit with a German name out on the volume from the Mac, stopped TextEdit, and successfully retrieved it. So it doesn't look like a filesystem mounting issue. I wonder what is so weird about these files. There must be something odd in the header, because it is definitely at the file info level that it is going off the rails. While the name is the obvious differentiator, maybe something else is odd as well.
One thing I could try is to zip one of the directories affected on the Windows side and then try unzipping it into place there, then boot over to the Mac side and see if things have improved. If that doesn't resolve the problem, I could try unzipping it into place on the Mac side, but first I'll boot over to the Windows side and make sure it can read the file I just created in TextEdit from that end.
By the way, the KB article you referenced was about shares and about problems with punctuation mounting Mac shares on Windows, so I don't think it pertains. In any case, I'm mounting a FAT volume, not a share, so the drivers would be completely different.
Anyway, thank you for your help. Now that I'm no longer chasing phantoms, I can attend the real problem.
Thanks,
Ralph

Importing music with international characters

I want to import some old music with international characters in the filenames (and probably id3 tag) into itunes.
I want to use the music in my car's mp3 reader which uses ms-dos and can't handle international characters. How can I get itunes to sort this for me when I import? can I get tunes to convert the French characters into ms-dos suitable ones?

Perhaps something at Doug's Scripts this would help, e.g. http://dougscripts.com/itunes/scripts/ss.php?sp=tracknameeditwithsed although doing it one character at a time might get a little dull. I've not spotted a "replace all non-ascii charcters" script but it shouldn't be too hard to create one.
tt2

Given filename or path contains Unicode or double-byte characters.Retry using ASCII characters for filename and path What does this mean? it happen when I publish an OAM

Given file name or path contains Unicode or double-byte characters. Retry using ASCII characters for filename and path
What does this mean? It is happening when I try to publish an OAM for Dreamweaver.
Also: How can I specify the browser in Edge Animate? It is just going wherever. Are there no Preferences for Edge Animate?
BTW. Just call it Edge. Seriously. Do you call it Illustrator Draw? Photoshop Retouching?

No, my file name is mainContent.oam
My project name is mainContent.an
This error happens when I try to import into Dreamweaver. Sorry, I wasn't clear on that earlier.
I thought maybe it was because I had saved my image as a png. So re-saved as a svg, still get the error.
DO I have a setting is Dreamweaver CC that is wrong? Should I try this in Dreamweaver CS6? I might try that next.
Why is this program so difficult? I know Flash. I know After Effects. I can work the timeline part just great. It's always in the export that I have problems.
On a MacPro, 10.7.
Are you an Adobe person or just a nice helper?

Problem with international characters showing up as junk

Hi All,
Little question.
I've made a xml data template which executes a query to fetch person names from the e-business suite tables.
However there are international characters in the names which are showing up incorrectly. When executing the query in the database everything shows up correctly. But when the query is executed via XML publisher the produced XML contains junk characters.
This is happening with for example o umlaut characters.
The database characterset is: WE8ISO8859P1
Version of XML publisher: 5.6.3
Patrick

This turned out to be an extra property which was set in the data template:
property scalable_mode with value "on"
This caused the special characters to be mangled.
Patrick

Parsing International Characters

Hi folks,
I am trying to parse an xml document which has international characters like "�" (accentuated e used in french). But my parser crashes trying to parse a document containing these characters:
System.out.println("******************* 1");
DocumentBuilderFactory lFactory = DocumentBuilderFactory.
newInstance();
System.out.println("******************* 2");
DocumentBuilder lDB = lFactory.newDocumentBuilder();
System.out.println("******************* 3");
lDoc = lDB.parse(new FileInputStream(pFileName));
System.out.println("******************* 4");
The exception occures after 3rd println. Here is what I get:
[17/May/2005 08:50:14:640] info: The Exception Stack Trace is : The element type "FirstName" must be terminated by the matching end-tag "</FirstName>".: org.xml.sax.SAXParseException: The element type "FirstName" must be terminated by the matching end-tag "</FirstName>".
 at org.apache.xerces.framework.XMLParser.reportError(XMLParser.java:1213)
 at org.apache.xerces.framework.XMLDocumentScanner.reportFatalXMLError(XMLDocumentScanner.java:579)
 at org.apache.xerces.framework.XMLDocumentScanner.abortMarkup(XMLDocumentScanner.java:628)
 at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1136)
 at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
 at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1098)
 at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:195)
 at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
 at com.exult.andy.mbcommon.utilities.AncestorXMLUtil.fileToDoc(AncestorXMLUtil.java:328)
 at com.exult.andy.importadapter.base.AncestorDeployImportAdapter.main(AncestorDeployImportAdapter.java:62)
The element is indeed correctly terminated.
I appreciate any help. Thanks in advance.
-r

Then you don't have a well-formed XML document. If it doesn't declare its encoding in its prolog <?xml version="1.0" ?> then it should be encoded in UTF-8 (or, less likely, some variant of UTF-16) and it's probably encoded in ISO-8859-1 or something like that. If that's the case then fix the prolog to declare the encoding: <?xml version="1.0" encoding="ISO-8859-1" ?> or encode the document in UTF-8.

BIG PROBLEM: CSS files not loading because of international characters in file name

I have Muse Beta 7 in Spanish.
The program creates a css file called master_a-página-maestra.css in css folder. It is referenced in the resulting HTML code here:

<link rel="stylesheet" type="text/css" href="css/site_global.css?3951792836"/>
<link rel="stylesheet" type="text/css" href="css/master_a-p%c3%a1gina-maestra.css?fileVersionPlaceholder"/>
<link rel="stylesheet" type="text/css" href="css/index.css?3948175564"/>
When you work locally in your Windows formatted har drive, everything looks fine, but when you upload your files to a server, everything is screwed up. The server doesn't recognizes the URL and returns an error page, resulting in style errors in the entire site.
This can also happens with html files if the title of the page contains international characters or with images if the image file name in your Hard Drive contains international characters.
I already pointed out long time ago Muse was generating file names with international characters like á, ñ, etc but nobody cared about it. Too bad. I had to activate file name customization but I think that Muse should replace automatically this characters in the same way that it replaces other conflictive characters like commas or ampersands.
This is not a fault of the FTP client. Accented characters are not web safe regardless of the FTP client you are using. It is a server side issue. Some servers support it some others don't. I don't mind if it works in Adobe Catalyst server because the final website is going to be in another server and maybe next year when paid hosting is ended the client may move it to another server.
It makes more sense to replace accented characters in file names by their not accented equivalents ('a' instead of 'á', 'N' instead of 'Ñ', etc) and avoid all this problem.

Zak, It is funny you mention it, because the site I am talking about is hosted in 1and1. try this: http://www.artofwalls.com/rosannawalls/biografía.html
As you can see, the offending "í" in the file name causes 1and1 server to throw a "page not found" error. And this has happened with many other servers I have tried since.
Muse boast of generating code fully compatible with all major web browsers but by using international characters in file names it ggenerates code suitable only for very few web servers. International characters have been always a no-no for internet URLs. Internet was designed by people who didn't care about ascii codes beyond 127 so using international characters in html file names is just call for problems.
"to work with your hosting provider to determine how to enable Unicode encoded (UTF-8) file names and HTML files on their servers" is not a viable solution most of the time unless you are a Very Important Client of your host provider. If not, making changes means money for them and if you are the only one who complains, they are going to just tell you to not use international characters in your names.

SAPSCRIPT: Printing international characters on ZEBRA; How to do?

Hi,
I use software NiceLabel software to design barcode forms. I upload the design to so10 Sapscript text and print it on the Zebra ptinter. I used device tape ASCIIPRI. The SAP system is unicode.
Now I need to print chinese pallet labels and I get unexpected problems. I found a lot information but no solution. Is it possible to print international charcters form SAPScript on Zebra?
I got the information from Zebra's White Paper: Solution for Printing International Characters. There it says:
"Unicode UTF-8 is embedded within Zebra printers."
"SAP Forms can be universal. Labels and forms ... do not need to be modified or recreated to print in different languages."
"SAP-developed UTF-8 device type and code page support for SAPscript users"
"Label design software that can generate ZPL with support for Unicode ZPL commands"
Do you now which device type I have to use? I think I need an UTF-8 device type. Do you know how to go on?
Please help. Thanks
Frank

Hi Frank,
as far as I know, it might be possible when using SMARTFORMS instead of SAPScript!
In that case, it depends of the device type and the printer type, of course.
Have a look on SAP Note 750002 SmartForms: Support für Zebra Etikettendrucker (ZPL2).
Cheers
Klaus

Problems with special Characters in filenames and folders

My problem is that i have a small portlet which lists some files under each other. These files have sometimes the special character & in there name.
If now a person clicks with right mousebutton on such a link, the saving dialog only shows a cryptik filename.
Example:
filename = harry&sally.pdf
rightclick and saving the file the new name is something like: 2C576B9904F63BBEE040200A2A040606.pdf
All other files even if they have blank characters or characters like ä, ö ... it works but not with &.
Do anyone could say me how i can manage this?
Message was edited by:
Oliver Lemm

having special characters in filenames is not a safe and healthy practice as you may see. this is specially true for the content that has to be displayed online using Oracle as Oracle uses & and ? for passing parameter values in dynamic URLs. 

I would recommend estimation of the cost of fixing filenames to tackle this issue rather than to get a way-around to just bury it again. if you are using Unix platform, it should not be more than a line worth of command to fix for all such files using stream-editors; in windows you may take some more. but i understand, changing filenames might require one to see the impact of those changes on all other places where these files have been called. 

with kind regards,
 
syed

International characters not showing up in certain apps?

I'm using Dreamweaver CS3 and international characters aren't showing up. There are blank spaces where they used to be. The characters are still there, it's just that they appear as blank spaces (I can copy and paste them and see them elsewhere).
This change occurred after I installed 10.6. Is there any way to fix this?

I've seen the same thing on Photoshop and Fireworks CS3, and even just the other day on iMovie '09, but I was still on Leopard – so are you sure it's Snow Leopard-related?
In my case, CS3 apps would show squares, and iMovie wouldn't even move the cursor (it wouldn't even let me enter curly quotes). With iMovie it was easily fixed by typing in TextEdit, then copying and pasting to iMovie. No success in CS3 apps, which categorically refused to enter any glyphs that weren't more or less standard Latin.

How to load the international characters by using the SQL*Loader(UNIX)?

Hi Everyone,
I am not able to load the international characters thru SQL*Loader which is calling from Unix. Whenever I load these characters , appears in DB such as Square box. Please help me how to resolve the issue.
Using version is:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE     10.2.0.4.0     Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production
Thanks in advance.
Regards,
Vissu.....

This may help
SQL> CREATE TABLE test_sqlldr_unicode (id INTEGER, name VARCHAR2(100 BYTE));
Table created.Now my data file.
1,"ABóCD"
2,"öXYZó"
3,"EFGÚHIJK"
4,"øøøøøøøøøøøøøøø"My control file.
LOAD DATA
CHARACTERSET WE8ISO8859P1
INFILE 'C:\test_sqlldr_unicode.txt'
REPLACE
INTO TABLE test_sqlldr_unicode
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(id INTEGER EXTERNAL , name )
{code}
Running the sqlldr
{code}
C:\>sqlldr USERID=hr/hr CONTROL=test_sqlldr_unicode.ctl LOG=test_sqlldr_unicode.
log
SQL*Loader: Release 10.2.0.1.0 - Production on Thu Dec 30 19:38:22 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Commit point reached - logical record count 5
C:\>
{code}
The table
{code}
SQL> SELECT * FROM test_sqlldr_unicode;
        ID NAME
         1 ABóCD
         2 öXYZó
         3 EFGÚHIJK
         4 øøøøøøøøøøøøøøø
SQL>
{code}

Firefox Chrome Showing ???? instead of International Characters

Hi,
I have a flash movie at this site
http://preview.tinyurl.com/5289rz
When you click on the rendered thumb nail (with a link
containing international characters) it takes you to a URL with
those same characters in IE 7 it displays international characters
and takes you to a correct page but in Firefox, Chrome and Opera
the international characters are displayed correctly in the flash
movie, but the URL turns those characters into question marks ????
and the pages shows a 404 not found error.
Firefox
http://www.site.com/video/??????_??????_???????_???????_???????_???_????????

Does that mean we should ignore those millions of users
around the world that would be plain foolish. I am here to get this
problem solved not to be told to just ignore users who use other
browsers.

Problem with the International characters u00E0, u00E8, u00EC, u00F2, u00F9

Dear Experts,
My requirement is to send data files from SAP to Hyperion(Data Warehouse Tool) via application server. Here few fields(can be material description/ Name/ Address) contain international characters like à, è, ì, ò, ù (this is an example). So I need to send their equivalent characters (i.e a, e, i , o, u) to Hyperion. that is when I create a file in application server characters a, e, i, o, u should
contain in the file.
I used ENCODING NON-UNICODE, UTF-8, DEFAULT but no use.
Pls assist me.
Thanks,
Dharmendra Gali

If you just have the couple of characters mentioned, use Jürgen's suggestion. Otherwise I'd recommend usage of SAP function module SCP_REPLACE_STRANGE_CHARS, which is much more comprehensive. Note that depending on your invocation though you might get multiple characters for some, e.g. ä to ae. To some degree you can control this, see my comments in Re: Removing diacritical (special & accented) characters in SAP.
Cheers, harald

Jforum international characters problem

Hi all,
Has anyone used jforum (www.jforum.net)? It is an open source forum software
I am having problems with international characters.
Please let me know if you have had so I'll post my question.
Thank you.

Hi,
So here is the problem. JFORUM is a very easy to use forum that can be set up within a short period of time. It is all nice UI configuration.
In admin control I reconfigure the forum to be in Russian.
When I store messages in DB and later on retrieve them they come up as question marks :(
I tried to alter the table but it did not work. Here is an example of one table:
create table jforum_posts_text
     post_id int(11) not null default '0',
     post_text text CHARACTER SET utf8,
     post_subject varchar(100) default NULL,
     primary key (post_id)
)engine=InnoDB default charset=utf8;Any ideas, help, suggestions?
Thank you.

Displaying International Characters

Some users have been concerned about the fact that Buzzword
does not display some international characters - ranging from Greek
to Russian. This is accentuated by the fact that we have Buzzword
users in well over 100 countries.
The problem occurs when users attempt to insert some
international characters - say, the Greek letter omega - and
Buzzword instead displays a dot on the screen. Here's what's going
on, for anyone interested:
Like virtually all modern software, Buzzword adheres to the
Unicode standard, where characters are defined with 16 bits,
resulting in a total of over 65,000 possible characters.
However, unlike most desktop software, Buzzword must use
something called "embedded fonts". This means that we can't read
fonts off a user's computer, but instead we have to download fonts
from our server.
This is where our challenge begins. A font family contains
characters - called "glyphs" when drawn on the screen - for some
portion of the 65,000 possible characters defined by Unicode. Each
available character is downloaded as a small program containing
instructions on how to draw the glyph. The instructions are
relatively small, but each takes time to download - you can see
evidence of this in our "loading fonts" progress bar.
For Buzzword to load relatively quickly, we need to limit the
number of characters downloaded with each of our seven font
families. Most people use far fewer than 65,000 characters, so for
our first phase of deployment, we identified a couple hundred
characters to download for each font family. Because our initial
market focus was North America, we chose characters from Latin-1,
the Western European character set.
The result: when a user attempts to enter the Greek letter
omega, Buzzword recognizes the Unicode character but does not have
the downloaded instructions to display the glyph on the screen. The
little dot that is displayed instead is an indication that the
requested glyph has not been downloaded with the font set.. If the
user were to export the document to be read by a desktop program,
the glyph would probably be displayed using the computer's fonts.
Longer term, we'll handle this differently by downloading
fonts dynamically, based on the document's contents and a user's
settings. In the meantime, we apologize to everyone who uses
characters outside the Western European set. We will work to get
you a solution as soon as we possibly can.

quote:
Like virtually all modern software, Buzzword adheres to the
Unicode standard, where characters are defined with 16 bits,
resulting in a total of over 65,000 possible characters.
Actually, Unicode (the standard) does not care about the
number of bits.
It has enough space to encode more than one million
characters, and the current version (Unicode 5.1) already encodes
more than 100,000 characters (
http://www.unicode.org/versions/Unicode5.1.0/)
quote:
Buzzword must use something called "embedded fonts".
Nothing prevents Flash/Flex from using fonts "html style".
In fact, Buzzword can add a "Generic sans-serif" font as an
option (font-family: Verdana, Arial, Helvetica, sans-serif;) with
zero effort.
The document will not look the same on all computers, but
this might be better than the current bullets.
So this is not a "must".

International characters in filenames on FAT32

Similar Messages

Maybe you are looking for