[FFmpeg-devel] file protocol with Unicode support

[Kirill Gavrilov]

2011/4/13 Nicolas George <nicolas.george at normalesup.org>

> As for the solution to your problem, I believe the best solution is to
> replace the open call in os_support.c.
>
Something like this (in attach)?

Having a different protocol will just make things more messier.
>
But parsing input file name as UTF-8 only for Windows we make confusion in
API.
As for me - there no much difference and these changes will not broke open
procedure
even in existing code. However some people that currently can enter
filenames in
system-defined code page (and contains the symbols outside the ASCII) will
got open file error.

2011/4/13 Nicolas George <nicolas.george at normalesup.org>

> Le quartidi 24 germinal, an CCXIX, Kirill Gavrilov a écrit :
> > OK, UTF-16 not so good. But this doesn't make it 'idiotic'.
> > Sure bytes order and backward compatibility with ASCII makes UTF-8 most
> used
> > today.
>
> Limited range + treacherous variable length + endianness problems + ASCII
> incompatibility + need for a new API, I think this is plenty enough to call
> it idiotic.
>
> > While using char* you need to know in which character encoding is your
> text.
>
> No you don't. The only people who need to know the character encoding are
> those who do linguistic and rendering operations on it. The other ones only
> need to pass the string around.
>
> > thats because it is very commonly used like that. From wiki:
>
> Well, not among programmers who are not already twisted by microsoft lingo,
> which is the majority here.
>
> > Code page or locale defined system-wide.
>
> Condolences.
>
> > And at another point I don't think that UTF-8 can be used within some
> locale
> > in Windows
>
> Condolences again.
>
> > Thats just a terms mismatch. Linux has locales. And in locales code pages
> > are defined.
>
> Again, no, there is no such thing. The LC_CTYPE locale defines linguistic
> categories and mappings for bytes sequences, that is as far as it goes.
>
> > But 3-4 years ago this was not true and locale mismatch cause the
> filenames
> > and probably something another were displayed wrongly (as abracadabra).
>
> You only get problems if your system is not coherent.
>
> As far as filenames go, ffmpeg never creates nor displays them, it only
> passes them around, so there is no place for problem.
>
> As for the solution to your problem, I believe the best solution is to
> replace the open call in os_support.c.
>
> Having a different protocol will just make things more messier.
>
> Regards,
>
> --
>   Nicolas George
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk2lgGUACgkQsGPZlzblTJPjJQCgwXDBOWH06FvqjWev/8z4QX2N
> yWYAn0WwHjqn72SHnj7PfVYgt4W8WGuZ
> =+2TL
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
-----------------------------------------------
Kirill Gavrilov,
Software designer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileU2.patch
Type: text/x-patch
Size: 2307 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110413/9c20eb52/attachment.bin>