Copying filenames with invalid characters in OSX

I'd like to copy some folders for back up to an external hard disk from the internal hard disk on my G4. Problem is that some of the folders contain files were created in OS 9 and their filenames contain "/" symbols which apparently are not acceptable in OS X (10.3.9) which I am now running. After trying to drag the folders containing the files to the external hard disk I get an error message saying that they can't be copied because some of the filenames contain invalid characters. The problem files are scattered among files in many folders all over my G4's internal hard disk, and the task of finding and manually changing each one's filename is daunting. Is there a way to find and replace "/" with "." ? or some other more automated fix of the invalid characters? I'd prefer to keep the original files in their current folders on the G4. thanks
G4   Mac OS X (10.3.9)  

Does any of this software do what you want?
(20586)

Similar Messages

  • Renaming files with invalid characters in their names on NTFS partitions, introduced by operating systems other than Windows

    Essentially, Linux created some files with colons (:) in the name on a NTFS partition where I have Windows installed. I have since uninstalled Linux, but now I can only view these files in Windows Explorer. I can't open them, I can't even rename them to
    correct the problem. It's as if they don't exist, because of the invalid search paths.
    If I try to rename them in Windows Explorer I get following message.
    The file name you specified is no valid or too long.
    Specify a different file name.
    Well isnt' that something?... isn't that nice? Windows is able to display these files, but it doesn't allow me to open them and it certainly doesn't like me to rename them. So why is it whining about it then, when I'm trying to help? It says "try a different
    file name". Yeah, right! Like I haven't tried that one already! It doesn't matter what file name I input it will never accept it.
    So what am I supposed to do now? Ditch Windows and go back to Linux? Surely, Microsoft doesn't like the sound of that. Sure, I could reinstall Linux or run a Linux live system to correct the problem. But what good is Windows then? I might as well switch to
    Linux altogether.
    After doing some research I now know by fact that it's (kind of) possible to rename files from UNIX and UNIX-like operating systems to those compliant with Windows by using something called file name character translation. To some level this is essential and
    necessary for Windows interoperability with other operating systems (Windows is not the only operating system in the world). But this seems to be very complicated and I can't get my head around it. My brain is in overload. I don't know where to start.
    Once there was a...
    There's the Windows Services for UNIX (SFU) 1.0, 2.0, 3.0, 3.5. The first two versions were based on MKS Toolkit, a package licensed by Microsoft from MKS Inc. The later versions were based on the similar Interix product, after Microsoft purchased the company
    that made it.
    Then there's the new Subsystem for UNIX-based Applications (SUA). These are services for UNIX components. They are supposed to have Client for NFS v3 included as well. But the server components from the SFU line is missing (e.g. Server for NFS). These are included
    in Server editions of Windows.
    Then there's the Microsoft Knowledge Base article
    289627: "How to Enable File Name Character Translation". This article seems to describe exactly my situation.
    Windows and UNIX operating systems have restrictions on valid characters that can be used in a file name. The list of illegal characters for each operating system, however, is different. For example, a UNIX file name can use a colon (:), but a Windows
    file name cannot use a colon (:). If a UNIX user attempts to create a file with a Windows illegal character on a Windows Services for UNIX network file system (NFS) share, the attempt is unsuccessful and the UNIX client computer receives an input or output
    error.
    It goes further than that. At first glance, this KB article also seems to offer a solution to this exact problem, with examples as shown below.
    For example, the following maps the UNIX colon (:) to a Windows dash (-):
    0x3a : 0x2d ; replace client : with - on server
    I checked these values in charmap.exe and they are correct. Except for 2D not being a "dash", it's rather a hyphen ("hyphen minus" to be exact), but these two have pretty much the same appearance and they get interchanged a lot, I'm sure
    they are used to it by now. (Yes, the characters! They don't mind.)
    Then there's this registry key.
    HKEY_LOCAL_MACHINE\Software\Microsoft\Server For NFS\CurrentVersion\Mapping
    Well, of course, I don't have Server for NFS. So this is a dead end. Well, actually, it was a dead end from the beginning...
    1. First of all, I'm not working with a network share on a NAS or SAN storage. The files are on the local disk drive where Windows is installed, so that's a DAS for you.
    2. I don't have SFU! Well obviously, I'm on Windows Vista! So that means SUA!
    3. SUA are service components only. No server components. Can you guess what that means? Yeah... no "Server for NFS" since it's a server component.
    4. Windows Vista is a client side operating system! Server for NFS is only offered for use with Windows Server systems.
    5. Back to square one!
    So there you have it. They all lived happy for the rest of their lives...
    I'm stuck here. Can someone tell me what to do? I mean beyond the obvious option to use Linux to fixa a Windows problem? The NTFS file system itself supports colons in file names. It's Windows that doesn't, and so by default it proclaims it invalid character.
    Surely, even a Windows client operating system like Windows Vista should be able to allow the user to at least rename files with invalid characters to something more sensible (from the system point of view) and valid, if not being able to open them as they
    are. Just add some crazy voodoo code to it and it will work. If you can make it possible on Windows Server with UNIX user-mode subsystem on NT kernel, then what's stopping you from giving the Windows client system the same benefit?
    So what now? Purchase a Windows Server 2012 R2 license, copy my invalid files to a NAS share with NFS on a UNIX or Linux system, and have a go at the Windows registry and Server for NFS? Yeah... you're right, it's probably a bit over the top...
    On a second thought... I might as well install Linux again. There are countless situations where Linux has helped me solve problems related to, and more often than not caused by Windows.

    Essentially, Linux created some files with colons (:) in the name on a NTFS partition where I have Windows installed. I have since uninstalled Linux, but now I can only view these files in Windows Explorer. I can't open them, I can't even rename them to
    correct the problem. It's as if they don't exist, because of the invalid search paths.
    If I try to rename them in Windows Explorer I get following message.
    The file name you specified is no valid or too long.
    Specify a different file name.
    Well isnt' that something?... isn't that nice? Windows is able to display these files, but it doesn't allow me to open them and it certainly doesn't like me to rename them. So why is it whining about it then, when I'm trying to help? It says "try a different
    file name". Yeah, right! Like I haven't tried that one already! It doesn't matter what file name I input it will never accept it.
    So what am I supposed to do now? Ditch Windows and go back to Linux? Surely, Microsoft doesn't like the sound of that. Sure, I could reinstall Linux or run a Linux live system to correct the problem. But what good is Windows then? I might as well switch to
    Linux altogether.
    After doing some research I now know by fact that it's (kind of) possible to rename files from UNIX and UNIX-like operating systems to those compliant with Windows by using something called file name character translation. To some level this is essential and
    necessary for Windows interoperability with other operating systems (Windows is not the only operating system in the world). But this seems to be very complicated and I can't get my head around it. My brain is in overload. I don't know where to start.
    Once there was a...
    There's the Windows Services for UNIX (SFU) 1.0, 2.0, 3.0, 3.5. The first two versions were based on MKS Toolkit, a package licensed by Microsoft from MKS Inc. The later versions were based on the similar Interix product, after Microsoft purchased the company
    that made it.
    Then there's the new Subsystem for UNIX-based Applications (SUA). These are services for UNIX components. They are supposed to have Client for NFS v3 included as well. But the server components from the SFU line is missing (e.g. Server for NFS). These are included
    in Server editions of Windows.
    Then there's the Microsoft Knowledge Base article
    289627: "How to Enable File Name Character Translation". This article seems to describe exactly my situation.
    Windows and UNIX operating systems have restrictions on valid characters that can be used in a file name. The list of illegal characters for each operating system, however, is different. For example, a UNIX file name can use a colon (:), but a Windows
    file name cannot use a colon (:). If a UNIX user attempts to create a file with a Windows illegal character on a Windows Services for UNIX network file system (NFS) share, the attempt is unsuccessful and the UNIX client computer receives an input or output
    error.
    It goes further than that. At first glance, this KB article also seems to offer a solution to this exact problem, with examples as shown below.
    For example, the following maps the UNIX colon (:) to a Windows dash (-):
    0x3a : 0x2d ; replace client : with - on server
    I checked these values in charmap.exe and they are correct. Except for 2D not being a "dash", it's rather a hyphen ("hyphen minus" to be exact), but these two have pretty much the same appearance and they get interchanged a lot, I'm sure
    they are used to it by now. (Yes, the characters! They don't mind.)
    Then there's this registry key.
    HKEY_LOCAL_MACHINE\Software\Microsoft\Server For NFS\CurrentVersion\Mapping
    Well, of course, I don't have Server for NFS. So this is a dead end. Well, actually, it was a dead end from the beginning...
    1. First of all, I'm not working with a network share on a NAS or SAN storage. The files are on the local disk drive where Windows is installed, so that's a DAS for you.
    2. I don't have SFU! Well obviously, I'm on Windows Vista! So that means SUA!
    3. SUA are service components only. No server components. Can you guess what that means? Yeah... no "Server for NFS" since it's a server component.
    4. Windows Vista is a client side operating system! Server for NFS is only offered for use with Windows Server systems.
    5. Back to square one!
    So there you have it. They all lived happy for the rest of their lives...
    I'm stuck here. Can someone tell me what to do? I mean beyond the obvious option to use Linux to fixa a Windows problem? The NTFS file system itself supports colons in file names. It's Windows that doesn't, and so by default it proclaims it invalid character.
    Surely, even a Windows client operating system like Windows Vista should be able to allow the user to at least rename files with invalid characters to something more sensible (from the system point of view) and valid, if not being able to open them as they
    are. Just add some crazy voodoo code to it and it will work. If you can make it possible on Windows Server with UNIX user-mode subsystem on NT kernel, then what's stopping you from giving the Windows client system the same benefit?
    So what now? Purchase a Windows Server 2012 R2 license, copy my invalid files to a NAS share with NFS on a UNIX or Linux system, and have a go at the Windows registry and Server for NFS? Yeah... you're right, it's probably a bit over the top...
    On a second thought... I might as well install Linux again. There are countless situations where Linux has helped me solve problems related to, and more often than not caused by Windows.

  • Filenames with unicode characters

    Hello, I have a question regarding filenames with unicode characters on an arabic windows xp.
    I have a string, which the user entered and want to create a file with this string as filename. So my question:
    Which unicode characters are allowed in a filename? I know, that on a german windows " / \ * ? < > : * are not allowed from the ASCII set, but which unicode chars are allowed? Is this language dependend on windows? Maybe there exists a method, which checks a string for this allowed characters.
    Thanks for your help

    AFAIK the illegal characters are always the same (you listed them already) and as long as the filesystem supports it (read: you use NTFS and not FAT) you may use any other unicode character.
    You might have troubles displaying those characters 'though if you don't happen to have the correct fonts installed, but that would only be a cosmetic issue.

  • Filenames with strange characters

    (With apologies if this is a previously answered question.)
    One of my Java programs copies users' home areas around our network. I'm getting filenotfoundexceptions with some of the users' files, specifically those which use extended character sets (we have many international students who use special programs to create files with e.g. Chinese characters). I'm at a loss to know how to diagnose this problem and would appreciate any advice. The filenames are retrieved as result of a listFiles() and the copy method uses BufferedInput\OutputStreams.
    David R.

    Your problem must be with the names of the files, rather than with the content. I did a few experiments and found that Java (I'm using SDK 1.3 on Windows 2000) can't open files with Cyrillic characters in the file name, either for input or for output. Throws a FileNotFoundException, as you said. There shouldn't be any problem with Chinese content if you're using input and output streams.
    So, the problem is diagnosed. There are several bug reports that sound like this. Don't know if it has been fixed in SDK 1.4.

  • Bash script to trim all filenames with special characters recursively?

    Hi,
    I have a 30 GB directory full of data I recovered from a friend's laptop after her Windows XP crashed. I'd like to burn that data, but I can't, because many of the filenames contain weird characters (spaces, accents, things even worse that my XTerm displays as inverted question marks). So, mkisofs exits with an error.
    I'd like to clean that mess up, but it would take months to do that manually. Well, I only know a very little Bash, but I think this problem is already too heavy for my modest knowledge. Here's the problem:
    - check the contents of directory ~/backup recursively
    - find files whose filenames contain characters other than [A-Za-z0-9] and then maybe "-" and "_" and ".".
    - replace these characters either by an "_" or just erase them
    Now how would I translate that into a little Bash script?
    Cheers...

    Heyyyyy... nice idea

  • Problems with Filenames with Chinese Characters

    I seem to have problems with filenames with 2-byte characters like Chinese, Japanese and Korean in various apps. The problems occur when i download chinese music and import into iTunes :
    1. Torrent ( and all other ) files with 2-byte characters filename become junk characters in Finder after download from Safari.
    2. Music files created/downloaded by uTorrent displays 2-byte characters correctly in Finder.
    3. These downloaded music files when imported into iTunes becomes junk characters.
    4. Let say I wish to have a list of all filenames from (2). I do a ls -R > abc.txt in Terminal. abc.txt displays the filenames correctly in vi. However they become junk characters again when view using TextEdit.
    I've selected Chinese, Japanese, Korean in International setting. This is not about input method, just want to get the filenames correct in Finder and iTunes. Any advice is appreciated.

    3. These downloaded music files when imported into iTunes becomes junk characters.
    The ID 3 tags need to be in Unicode.
    http://homepage.mac.com/thgewecke/mlingos9.html#itunes
    4. they become junk characters again when view using TextEdit.
    TextEdit needs to be set to the correct encoding, it's not automatic.

  • Column values with invalid characters

    How to find the column values with invalid chararcters
    meaning value upper(col) not in ('ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890')
    For ex.
    1. CDAssyKit,DragonNaturallySpeaking�Preferred7.0,USEnglish
    2. CDAssyKit,DragonNaturallySpeaking Preferred7.0,USEnglish
    Query should retrieve only the first row, since it has extra � character in the column value.
    Thanks for your help.

    Convert all letters and numbers to an arbitrary letter and then remove that letter. If there are any characters left, they are invalid according to your rules.
    select *
      from t
    where replace(translate(lower(column_name), 'abcdefghijklmnopqrstuvwxyz0123456789', 'a'), 'a') is not null;

  • Problem figuring out the encoding for filenames with special characters

    I'm not sure if this is the right forum, but this does seem like an OS issue.
    I brought in a lot of mp3 and m3u files from a Windows machine to my new Mac. Some of the mp3 files have accented characters in their names, and these names appear in the m3u files. But if I add the m3u file to iTunes, it fails to recognize these names and so I lose all the mp3's with special characters in their names.
    I tried to fix this by grabbing the files name in Python, but that didn't work either!
    Here's an example: the file's name is "Voilà l'été.mp3"
    The m3u files says "Voil\xe0 l'\xe9t\xe9.mp3" -- this doesn't work.
    From os.listdir(), I get Voila\xcc\x80 l'e\xcc\x81te\xcc\x81.mp3", but sticking it in an m3u files doesn't work either. (Note that here the characters are encoded as unaccented letter + two byte code for the accent).
    When I try these strings from python, e.g. doing os.stat(), they both work; but iTunes doesn't understand any of them!
    I'd appreciate any hints on how to enter these names in the m3u file so that iTunes can read it. Thanks!

    I know nothing about "m3u" files and how iTunes interprets the file names in them, but if it is not a relative/absolute path problem, then how about just putting the raw file names (not the ones with backslash escape) in m3u file? For example, just put
    Voilà l'été.mp3
    in m3u?
    As for Unicode encoding, HFS+ file system uses the "decomposed form" for accented characters. This means, as you write, à is hex "61 cc 80" in UTF-8, i.e., "a + COMBINING GRAVE ACCENT". The pre-composed form is hex "c3 a0". But my experience is that in most cases both pre-composed and decomosed forms work at the user level (not at the lowest file system level).

  • Problem crawling filenames with national characters

    Hi
    I have a big problem with filenames containing national (danish) characters.
    The documents gets an entry in in wk$url but have error code 404 (Not found).
    I'm running Oracle RDBMS 9.2.0.1 on Redhat Advanced Server 2.1. The
    filesystem is mounted on the oracle server using NFS.
    I configure the Ultrasearch to crawl the specific directory containing
    several files, two of which contains national characters in their
    filenames. (ls -l)
    <..>
    -rw-rw-r-- 1 user group 13 Oct 4 13:36 crawlertest_linux_2_fxeFXE.txt
    -rw-rw-r-- 1 user group 19968 Oct 4 13:36 crawlertest_windows_fxeFXE.doc
    <..>
    (Since the preview function is not working in my Mozilla browser, I'm
    unable to tell whether or not the national characters will display
    properly in this post. But they represent lower and upper cases of the
    three special danish characters.)
    In the crawler log the following entries are added:
    <..>
    file://localhost/<DIR_PATH>/crawlertest_linux_2_B|C?C%C?C?.txt
    file://localhost/<DIR_PATH>/crawlertest_linux_2_B|C?C%C?C?.txt
    Processing file://localhost/<DIR_PATH>/crawlertest_linux_2_%e6%f8%e5%c6%d8%c5.txt
    WKG-30008: file://localhost/<DIR_PATH>/crawlertest_linux_2_%e6%f8%e5%c6%d8%c5.txt: Not found
    <..>
    file://localhost/<DIR_PATH>/crawlertest_windows_B|C?C%C?C?.doc
    file://localhost/<DIR_PATH>/crawlertest_windows_B|C?C%C?C?.doc
    Processing file://localhost/<DIR_PATH>/crawlertest_windows_%e6%f8%e5%c6%d8%c5.doc
    WKG-30008:
    file://localhost/<DIR_PATH>/crawlertest_windows_%e6%f8%e5%c6%d8%c5.doc:
    Not found
    <..>
    The 'file://' entries looks somewhat UTF encoded to me (some chars are
    missing because they are not printable) and the others looks URL
    encoded.
    All other files in the directory seems to process just fine!.
    In the wk$url table the following entries are added:
    (select status url from wk$url where url like '%crawlertest%'; )
    404 file://localhost/<DIR_PATH>/crawlertest_linux_2_%e6%f8%e5%c6%d8%c5.txt
    404 file://localhost/<DIR_PATH>/crawlertest_windows_%e6%f8%e5%c6%d8%c5.doc
    Just for testing purpose a
    SELECT utl_url.unescape('%e6%f8%e5%c6%d8%c5') from dual;
    Actually produce the expected resulat : fxeFXE
    To me this indicates that the actual filesystem scanning part of the
    crawler can sees the files, but the processing part of the crawler can
    not open the file for reading and it therefor fails with error 404.
    Since the crawler (to my knowledge is written in Java i did some
    experiments, with the following Java program.
    import java.io.*;
    class filetest {
    public static void main(String args[]) throws Exception {
    try {
    String dirname = "<DIR_PATH>";
    File dir = new File(dirname);
    File[] fs = dir.listFiles();
    for(int idx = 0; idx < fs.length; idx++) {
    if(fs[idx].canRead()) {
    System.out.print("Can Read: ");
    } else {
    System.out.print("Can NOT Read: ");
    System.out.println(fs[idx]);
    } catch(Exception e) {
    e.printStackTrace();
    The performance of this program is very depending on the language
    settings of the current shell (under Linux). If LC_ALL is set to "C"
    (which is a common default) the program can only read files with
    filenames NOT containing national characters (Just as the Ultrasearch
    crawler). If LC_ALL is set to e.g. "en_US", then it is capable of
    reading all the files.
    I therefor tried to set the LC_ALL environment for the oracle user on
    my oracle server (using locale_config, and .bash_profile) but that did
    not seem to fix the problem at hand.
    So (finally) my question is; is this a bug in the Ultrasearch crawler
    or simply a mis configuration of my execution environment. If the
    latter how do i configure my system correctly?
    Yours sincerely
    Martin Dahl Pedersen, Visanti ( mdp at visanti dot com )

    I've posted my problems as a TAR on METALINK a little week ago.
    And it turns out to be a new bug in UltraSearch.
    It is now filed under BUG:2673282
    -- mdp

  • Unable to Empty Trash - Files with invalid characters

    I have tried everything I can find on the internet to empty my Trash of these two files:
    "Empty Trash" does nothing.  Terminal commands (rm -rf and the like) result in "Directory not empty" or "No such file or directory".
    Any help most appreciated.

    Here are suggested solutions from other threads:
    https://discussions.apple.com/message/19055838#19055838
    https://discussions.apple.com/message/19508937#19508937
    https://discussions.apple.com/message/15860098#15860098

  • Filenames with non-latin characters aren't found by the filesystem [S]

    This might be a bug, but I'm hoping it's just a config file problem.
    I have a few files here and there on my NTFS drive that have Japanese characters in their filenames.  Sometime recently (I don't have an exact date when they disappeared), they stopped showing up at all.  If I browse to a folder that used to contain filenames with Japanese characters, it just appears empty in Gnome.  Using ls from a terminal also says the directory is empty.  They used to work just fine, but a recent upgrade must have broken them.
    Does anyone have any ideas what I can do to get my files to appear again?  Is there some way to enable unicode support for filenames or something?
    Many thanks!
    Edit: Rebooting the system fixed it, though I still think that was a pretty strange problem.  Any ideas what was up?
    Last edited by ColdPie (2007-11-11 02:07:11)

    The funny thing is that bold font [when message unread in message list] shows OK, ie in greek, but when i click on unread message, it is assumed to have been read, so it changes over to medium [non bold] and the encoding changes as well into the one that is not greek and thus unreadable.  In ~/.sylpheed/sylpheedrc the fonts are:
    widget_font=
    message_font=-microsoft-sylfaenarm-medium-r-normal-*-*-160-*-*-p-*-iso8859-7
    normal_font=-monotype-arial-medium-r-normal-*-12-*-*-*-*-*-iso8859-7
    bold_font=-monotype-arial-bold-r-normal-*-12-*-*-*-*-*-iso8859-7
    small_font=-monotype-arial-medium-r-normal-*-12-*-*-*-*-*-iso8859-7
    In /etc/gtk, for gtk1.2 apps the file refering to greek encoding [el] seems to be fine [exactly the same as in slackware 9.1].

  • Need help with Value '# ' of 0REF_DOC_NO contains invalid characters

    Hi Experts
    We are having load failure due to this Value '# ' of characteristic 0REF_DOC_NO contains invalid characters error. I have managed to find out at PSA level there are few records with contains # value. I have also informed the user about it and user had rectified the record from ECC level.
    Our load goes evey night through process chains from PSA to DSO and then to Cube.
    We have requests in DSO till today and the problem happened two weeks ago e.g. 7 DEC. In cube the last record came on 6 DEC as after that it was failing everyday.
    Now I am just wondering with few questions :-
    Should I wait for next delta load to happen so that it can bring all the records from DSO to Cube or Do i need to change the record of that certain date in DSO too.
    Please give me your valuable suggestion and steps.
    Regards
    Sunny

    Sorry for posting it in wrong section, i have moved it to right thread now.
    Cube is failing with invalid characters error Value #  of 0REF_DOC_NO

  • Invalid characters (URGENT please)

    Hello,
    I have two independent systems where in one of the systems users maintain characters like (Á É Í Ó Ú Á É Í Ó Ú Ä Ë Ï Ö Ü….etc). I am not sure how many different type of characters users maintain but I want to populate all of these in the master data.
    Because I do not know all the Special characters, I cannot mention all of them in RSKC. Is there any functional module that converts special characters like mentioned above in to English? ALTERNATIVELY, is there any other work around to sort it out
    I cannot use ALL_CAPITAL in RSKC as well.
    Thanks and Regards,
    Harish Mulaka

    Apparao,
    We created a Function Module with this code and just call it in the Tranfer Rules for the specific InfoObject with Invalid Characters issue. It replaces any invalid character by " " (space).
    ""Local Interface:
    *"  IMPORTING
    *"     REFERENCE(I_VALUE)
    *"     REFERENCE(I_INFOOBJECT) TYPE  RSD_IOBJNM
    *"  EXPORTING
    *"     VALUE(O_VALUE)
    DATA: length       TYPE I,
           index        TYPE I,
           current_char TYPE C,
           result(60)   TYPE C,
           infoobject   TYPE RSD_IOBJNM.
    CLEAR: result,
            infoobject.
    MOVE I_VALUE      TO result.
    MOVE I_INFOOBJECT TO infoobject.
    TRANSLATE result TO UPPER CASE.
    length = strlen( result ).
    index  = -1.
    DO length TIMES.
      index        = index + 1.
      current_char = result+index(1).
      CALL FUNCTION 'RSKC_CHAVL_OF_IOBJ_CHECK'
       EXPORTING
        I_CHAVL            = current_char
        I_IOBJNM           = infoobject
      I_S_COB_PRO        =
      I_T_COB_PRO_CMP    =
       EXCEPTIONS
        CHAVL_NOT_ALLOWED  = 1.
      IF SY-SUBRC <> 0.
       MOVE ' ' TO result+index(1).
      ENDIF.
    ENDDO.
    MOVE result TO O_VALUE.
    ENDFUNCTION.
    A sample call:
    CALL FUNCTION 'ZFM_ELIMINATE_INVALID_CHARS'
        EXPORTING
          I_VALUE      = TRAN_STRUCTURE-0MATERIAL
          I_INFOOBJECT = '0MATERIAL'
        IMPORTING
          O_VALUE      = RESULT.
    Hope it helps.
    Regards,
    Luis

  • Does photoshop cs5 sdk support file names with unicode characters?

    Hi,
    For the export module, does the windows sdk have support for filenames with unicode characters?
    The ExportRecord struct in PIExport.h has an attribute filename declared as char array.
    So I have a doubt whether filenames with unicode characters will be supported for export module.
    Thanks in advance,
    Senthil.

    SPPlatformFileSpecificationW is not available in ReadImageDocumentDesc.
    It has SPPlatformFileSpecification_t which is coming as null for export module.
    I am using phostoshop cs5 sdk for windows.
    Thanks,
    Senthil.

  • Language:  Filename with characters for arabic turns question mark

    Language: Filename with characters for arabic turns question mark
    OS: Solaris 9
    Machine: Sun-Fire 25K
    There is an adobe distiller software that is configured and a java apps. There are postscript files that are being converted to .pdf format using the adobe distiller. Using the GUI (using the Exceed; for remote access), when they use GUI to convert the postscripts to pdf files, the long filenames have the corresponding characters for arabic reading purpose. This is OK.
    When we use the windows RUN to telnet the server and convert the postscripts to pdf, it gives a question marks characters in the filenames ( this; is a sample; filename; ?? ??? ??; right.pdf )
    We are not sure now if we have to add a package of arabic or a patch to resolve this problem.
    Message was edited by:
    yurioira32
    Message was edited by:
    yurioira32

    Solution found, I'll post the work around to those who might encounter the same problem.
    Somewhere in the layers of technology (webwork or weblogic I'd guess), the servlet response is encoded into UTF-8 regardless. The encoding in the database was ISO-8859-1. Sending ISO encoded bytes by UTF-8 caused the conflicting character codes (anything above 127) to show up as undefined.
    The fix is to decode the input byte array into ISO-8859 string, then encode that string into UTF-8, which can be send by Weblogic.
    isoConvert = new String(buf, "ISO-8859-1");
    out.write(isoConvert.getBytes("UTF-8"), 0, isoConvert.getBytes("UTF-8").length);

Maybe you are looking for