#169 Problem with spanish unicode characters in filenames

v2.5x
open-postponed
nobody
Internals (76)
7
2006-11-03
2006-01-16
Sven Rieke
No

While using a new feature of MeGUI, I realized that
there seems trouble with accent caracters in AVS scripts.

I attached the temporary avs script generated by MeGUI.

The problem consists in these two lines:

<snip>
file="C:\Documents and Settings\Sven
Rieke\Configuración local\Temp\interlace.log"
c = WriteFile(c, file, "a", "sep", "b")
<snip>

AviSynth blames that it can't open the file for writing.

Taking out the "ó" of the filename make's the thing
work, so this is the caracter which makes avisynth fail.

Discussion

  • Sven Rieke
    Sven Rieke
    2006-01-16

    Script generated by MeGUI that fails to load on spanish windows system

     
    Attachments
  • Johan Larsson
    Johan Larsson
    2006-01-22

    Logged In: YES
    user_id=983613

    I want to report the same thing - there's an "ä" in the name
    of my system Temp path, and it seems like avisynth can't
    handle that for writing. Changing my path, then it works.

     
  • Ian Brabham
    Ian Brabham
    2006-04-07

    • summary: Problem with spanish unicode caracters in script --> Problem with spanish unicode characters in filenames
     
  • Ian Brabham
    Ian Brabham
    2006-04-22

    • assigned_to: nobody --> ianb1957
     
  • Ian Brabham
    Ian Brabham
    2006-04-22

    Logged In: YES
    user_id=673887

    WriteFile() uses the standard C library "fopen" call. Under
    a standard US English code page environment these
    characters appear to work correctly. Most of avisynth uses
    these similar "char" based file-i/o calls.

    However DirectShowSource uses widechar filename calls. It
    uses "MultiByteToWideChar(CP_ACP, ..." to do the filename
    widechar translation.

    Can you please confirm if DirectShowSource() has similar
    issues with extended character filenames or works correctly
    under your language environment.

     
  • Ian Brabham
    Ian Brabham
    2006-04-23

    Logged In: YES
    user_id=673887

    Also what version of windows are you using?

     
  • Sven Rieke
    Sven Rieke
    2006-04-25

    Logged In: YES
    user_id=1428104

    Hi ianb1957, I tried your suggested test.

    You're right, DirectShowSource() works correctly with this
    extended character filename.

    So the problem lies in the fopen() call of mpeg2source(),
    WriteFile() etc.

    BTW, I'm using AviSynth 2.57 (2006-03-26) and Windows XP, SP2.

     
  • Ian Brabham
    Ian Brabham
    2006-11-03

    Logged In: YES
    user_id=673887

    Well I'm fresh out of ideas and things to try. I'll put this
    back in the pool until somebody has a constructive idea to
    offer.

     
  • Ian Brabham
    Ian Brabham
    2006-11-03

    • priority: 5 --> 7
    • assigned_to: ianb1957 --> nobody
    • status: open --> open-postponed
     
  • Logged In: NO

    AviSynth has absolutely nothing to do with Unicode. This is not just filenames – the entire language design is for Win98 based systems. You can use only one codepage at time, and if the character you want to use is not present in any existant Windows codepage (that is, most of the Unicode characters), you can't use it. In many cases some of the functions, like „Subtitle“ make little sense.

    Adding Unicode support means completely redesigning AviSynth 2. And probably this will never be done. Just stick to VirtualDub if you need something in Unicode.

     
  • Ian Brabham
    Ian Brabham
    2007-10-09

    Logged In: YES
    user_id=673887
    Originator: NO

    Dear nobody (please sign messages when anonymous)

    Yes Avisynth scripts are 8 bit character, ansi text, files and have to stay that way.

    The bottom line of the problem seems to be, that the way the standard C library ansi calls translate 8bit to unicode is not as expected. When the translation from 8bit to unicode is done manually, like in DirectShowSource, things work as expected.

    Maybe that will have to be the solution, to manually translate 8bit to unicode as done in DirectShowSource and use the ---W versions of the affected calls.

    This should not be necessary because the ---A versions of the library calls used are supposed to be doing this exact same translation already.

    I am sure somebody will eventually provide the missing piece of this puzzle (I am monitoring this tracker).

     
  • Logged In: NO

    "Yes Avisynth scripts are 8 bit character, ansi text, files and have to
    stay that way."

    May I ask what "have to stay that way" means?

     
  • Ian Brabham
    Ian Brabham
    2007-10-09

    Logged In: YES
    user_id=673887
    Originator: NO

    Who are you? (At least give a Nick so I know you are the same person each time).

    *.avs files are defined as being 8Bit text files. Everything currently expects that, so it cannot change without pissing everybody off.

    To do unicode would be a totally separate, independant interface with a different file extension and api calls.

    If you wish to discuss this further open a thread in "Avisynth Development" at http://forum.doom9.org/ this bug tracker is not the most conveinient place to chat. Or use the web form here to send me (ianb1957) a private message.