Unicode file names support

[GoogleCodeExporter]

Any plans to support Unicode file names (or I just don't know how to build
lib with Unicode support)?

Original issue reported on code.google.com by eriks.al...@gmail.com on 14 Dec 2009 at 5:26

[GoogleCodeExporter]

I'm going to fix this--there are a few options:

- Change all the filename parameters in mp4v2 to const wchar_t* (along with 
required
file system call changes)
- Add sibling "XyzUtf8" version of functions that take const char* so that 
existing
calls expecting the "local 8 bit" didn't break on other people unexpectedly, 
and then
use UTF-8 for file names, converting to wchar_t and unicode where needed.
- Same thing as 2nd, but just change existing functions to mean utf-8 when they 
pass
const char* 

This is unfortunately a complicated problem, and particularly so because the 
POSIX
implementation uses fstream.open, which has different meanings depending on the
platform.  Under OSX, it's implied that fstream.open accepts a UTF8 string, but 
that
isn't the case with gcc or most windows compilers.

Anyone have any thoughts on this?

By the way, an easy way to reproduce this issue is simply name a file 
"Nàáâãåæmé 姓名
测试 зиøù Tửst.mp4," and MP4v2 probably will not be able to open the 
file.  Rename it
to something in your local 8-bit code page and I think you're okay.

Original comment by kid...@gmail.com on 1 Apr 2010 at 2:26

[GoogleCodeExporter]

Hmm...in doing a bit more research, another option (I think?) is to use
MP4CreateProvider.  Might look into that more--it may be that the best solution 
is a
completely separate file provider than the ones the default library provides. 

If I go this route, it'll probably be something based on Qt's QFile

Original comment by kid...@gmail.com on 1 Apr 2010 at 2:30

[GoogleCodeExporter]

A provider unfortunately isn't an option due to the calls in 
FileSystem_win32.cpp,
which reference the ASCII versions of all the primitive functions.  Doh.

e.g.:

bool
FileSystem::getFileSize( string path_, File::Size& size_ )
{
    size_ = 0;
    WIN32_FILE_ATTRIBUTE_DATA data;
    if( !GetFileAttributesExA( path_.c_str(), GetFileExInfoStandard, (LPVOID)&data ))
        return true;
    size_ = ((File::Size)data.nFileSizeHigh << 32) | data.nFileSizeLow;
    return false;
}

...also, these should really be part of the file provider interface.  I'm not 
sure
why file provider doesn't encompass all of this.

Original comment by kid...@gmail.com on 1 Apr 2010 at 6:50

[GoogleCodeExporter]

Issue 55 has been merged into this issue.

Original comment by kid...@gmail.com on 2 Apr 2010 at 12:46

[GoogleCodeExporter]

r375 should fix this issue, at least on win32.  On *nix and OSX, there may be 
more
work to do.  I ended up going with option #3 (change existing functions to mean 
utf-8
when they pass const char*); if anyone has feedback on the implementation, I'd
welcome that.

closing this.

Original comment by kid...@gmail.com on 2 Apr 2010 at 8:19

• Changed state: Fixed