Menu
▾
▴
#169 Problem with spanish unicode characters in filenames
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.
Script generated by MeGUI that fails to load on spanish windows system
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.
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.
Logged In: YES
user_id=673887
Also what version of windows are you using?
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.
Logged In: YES
user_id=673887
See http://forum.doom9.org/showthread.php?p=819708 for
discussion
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.
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.
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?
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.