[MPlayer-dev-eng] [PATCH] use system locale instead of C locale

[KO Myung-Hun]

Hi/2.

Reimar Döffinger wrote:
> On Sun, May 24, 2009 at 02:37:33PM +0900, KO Myung-Hun wrote:
>   
>> KO Myung-Hun wrote:
>>     
>>> Reimar Döffinger wrote:
>>>       
>>>> On Tue, May 19, 2009 at 11:20:02PM +0900, KO Myung-Hun wrote:
>>>>  
>>>>         
>>>>> I've fixed by allocating buffer for 'charset'. OS/2 implementation 
>>>>> of nl_langinfo( CODESET ) returns the static variable. So even 
>>>>> though if we got 'charset' by setting locale to system one, it is 
>>>>> changed to new one after setting locale to C. But we should accept 
>>>>> memory-leak. Fine ?
>>>>>     
>>>>>           
>>>> The generic (in getch2.c) code needs the same change.
>>>> Also the code for getch2-win.c should be changed to use malloced memory
>>>> too, and get_term_charset get a documentation stating it will return
>>>> a malloced string.
>>>>         
>>> Ok. I'll do that later.
>>>       
>> I did.
>>     
>
> Applied though I extended the documentation and instead added it to the
> declaration in mp_msg.c
>
>   

Thanks. ^^

>>>> IMO unless someone has a better idea, the source charset should just be
>>>> set to UTF-8.
>>>>   
>>>>         
>>> I think we'd better introduce a option whether to use UTF-8 or 
>>> national characters for URL such as -usenlsurl as IE does.
>>>
>>>       
>> I used 'MPLAYER_CHARSET'. If it is not set, UTF-8 is used.
>>     
>
> I don't really care (it currently is broken anyway and can't really get
> any worse), but MPLAYER_CHARSET is supposed to be the charset used for
> output, not the command line/URLs, at least that's how it is documented
> I think.
>
>   
>> Index: stream/asf_mmst_streaming.c
>> ===================================================================
>> --- stream/asf_mmst_streaming.c	(revision 29289)
>> +++ stream/asf_mmst_streaming.c	(working copy)
>> @@ -533,6 +533,9 @@
>>    char                *path, *unescpath;
>>    URL_t *url1 = stream->streaming_ctrl->url;
>>    int s = stream->fd;
>> +#ifdef CONFIG_ICONV
>> +  const char *url_charset;
>> +#endif
>>
>>    if( s>0 ) {
>>  	  closesocket( stream->fd );
>> @@ -574,12 +577,12 @@
>>
>>    /* prepare for the url encoding conversion */
>>  #ifdef CONFIG_ICONV
>> -#ifdef HAVE_LANGINFO
>> -  url_conv = iconv_open("UTF-16LE",nl_langinfo(CODESET));
>> -#else
>> -  url_conv = iconv_open("UTF-16LE", NULL);
>> +  url_charset = getenv("MPLAYER_CHARSET");
>> +  if (!url_charset)
>> +    url_charset = "UTF-8";
>> +
>> +  url_conv = iconv_open("UTF-16LE", url_charset);
>>  #endif
>> -#endif
>>     
>
> I removed the nl_langinfo stuff which should at least reduce the size of
> this diff a bit.
> I still think it is ugly, but probably misusing mp_msg_charset might be
> the best solution.
> On the other hand, I think it would collide with proper support of
> unicode files/URLs on Windows, because there the commandline would be
> passed in as UTF16-LE (and we'd probably convert to UTF-8), so then the
> commandline (and thus URL) charset has no relation at all with the
> terminal charset...
>   

If so, how about introducing a new environmental variable, 
MPLAYER_URL_CHARSET and a new command line option, -urlcharset ? By 
this, we can use a separate charset from the terminal charset.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 1.1.16
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1 GHz with 512 MB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: url_charset.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090602/b1e459bf/attachment.asc>