Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dnd of filenames with locale specific characters

After checking stderr for messages the following is generated when a character in the absolute path of the File instance is an <o-acute>

java[814] Couldn't convert path "/Volumes/Seagate1/Music/Fijacio?n Oral, Vol. 1/01 En Tus Pupilas.m4p" to an FSRef to put on the pasteboard.
dragEnter

This is the same message as reported by Pierre.

This message is generated even before I can drag out of the Swing application frame.

The DragGestureRecognizer is created using the DnDConstants.ACTION_COPY and startDrag is called using ds.startDrag(dge,DragSource.DefaultCopyDrop, ftrans,  this); where ftrans is a Transferable created using an array of Files. 

If multiple files are involved in the transfer the Finder target rejects the drop entirely.  Interestingly enough the TextEdit.app accepts the drop with multiple files and displays the incorrectly translated path with a ? instead of the <o-acute> character. 

On Jul 10, 2006, at 1:47 PM, Greg Guerin wrote:

Please try your DnD experiment using a filename with the following instead
of <o-acute>:
  bullet  (shift-option-8 on US English keyboard)
  ae-ligature   (option-' on US English keyboard)


Using the options above resulted in different failures. 

Using bullet (shift-option-8) with a filename of 01 Esto°y Aqui.m4p resulted in an error of:

2006-07-10 20:26:35.644 java[809] *** NSThread: ignoring exception '*** -[NSCFArray addObject:]: attempt to insert nil' that raised during delayed perform of target 0x3cb7d0 and selector 'doDrag'

Using ae-ligature (option-') with a filename of 01 Estoæy Aqui.m4p resulted in the same error of:

2006-07-10 20:30:06.534 java[810] *** NSThread: ignoring exception '*** -[NSCFArray addObject:]: attempt to insert nil' that raised during delayed perform of target 0x3ca1c0 and selector 'doDrag'

When all the special characters are removed from the path and filename, the transfer works perfectly. 


Also, I'm curious what action the Finder takes when the drop works.  Does
it move the files or copy them or what?

Finder just copies the files. No move is involved. 


Does the Finder act on a partial list?  If the list contained "abc.txt"
followed by "abc<o-acute>.txt", would it act on the first file but fail on
the second, or does it reject the entire list?


Finder will not act on any element in the array if one of the File instances in the array contains the <o-acute> character as part of its path.


Dropping the file from the java swing app to different targets also
exhibits the same failure.

Which "different targets":
  a) other Swing targets in the same Java app;
  b) other Swing targets in another Java app;
  c) other non-Java apps, e.g. TextEdit.app?

I only tested dropping to other non-Java apps. Dropping to a mail message from the java swing app as an attachment fails in the same manner. I have not yet tested other java apps in different jvms. I would guess this would fail since it is reaching into the native os. I'll have to try between components in the same jvm. I'm not sure what to expect here. 


Does dropping a transferable without the problematic characters work?  That
is, if you dropped an "abcdef.txt" file-list on a TextEdit.app window, does
it expand to the full pathname?


Yes, dropping a file on TextEdit.app without any special characters expands to the full pathname. 

Dropping the problematic file on TextEdit.app displays the path with "?" for the characters it could not decode. 
Dropping a list of files including the problematic file on TextEdit.app displays the full pathname for all the files including the incorrect path 
of the file containing the <o-acute>.

It looks like I'll need to submit a bug report to Apple. I suspect there is a character set encoding issue when translating the java File instance to a native FSRef instance. I don't think Mac OS X uses UTF-8 as the default character encoding so some form of encoding transformation must be taking place and certain characters appear not translate correctly disrupting the transfer. Perhaps a large number of locale specific characters may fail. 

Just for grins I setup a file using a single byte Katakana character ｼ as part of the filename. Don't ask me what it means I just copied the character Word inserted into a document. This had the same failure as <o-acute>. I also tried a Greek/Russian character, リ, and it also had the same failure. Finder to Finder based transfers worked great using these characters. 

A workaround if non-ascii characters are found in the absolute path maybe to create a temporary file in a "safe" location from the original removing the non-ascii characters. This is not too appealing especially if the files are large but I'm not sure how else to proceed. Also, if the files only contain non-ascii characters for the filename they won't be transferable at all. 

I'll try on Windows XP over the next day or so as well to see if the behavior is any different. 

Thanks for all the replies. 

Bob Potterveld
 


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: dnd of filenames with locale specific characters (From: Greg Guerin <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.