[ruby-core:19517] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch))

Hi,

At Sun, 26 Oct 2008 11:25:58 +0900,
Michael Selig wrote in [ruby-core:19515]:
> 1)
> My preference would be to *always* encode string literals constructed with  
> "\x.." as ASCII-8BIT, ignoring the source encoding. This means that if you  
> really want to use such a literal as an encoded string, you must use  
> "force_encoding". I think this would be much clearer and get rid of the  
> "ambiguity".

> 2)
> My suggestion for "defaulting" the source encoding was an attempt to avoid  
> having to do this (but probably not a good way!). It isn't a big deal, and  
> I understand the argument that the source encoding is a property of the  
> script. My original suggestion (last month) of a special magic comment was  
> to have a way of specifying BOTH the default_internal and source encoding  
> once, but this idea was rejected.

I'd prefer to default the internal encoding to the source
encoding of the main script.

> 3)
> Perhaps this check could be based on the library's source encoding? If  
> this were done, most libraries would have to use a source encoding of  
> US-ASCII (or just have no encoding magic comment) *not* UTF-8, so that  
> non-Unicode default_internal's will work. Perhaps Ruby could be smarter,  
> and only flag an error if there actually is an incomaptible string literal  
> in the library?

What about comments?  I suspect it might not a good idea.

> 4)
> Also it means that:
> 	ruby test.rb
> may perform differently than:
> 	ruby -e "`cat test.rb`"

magic comments are effective with -e too.

$ ruby19 -e 'p __ENCODING__'
#<Encoding:EUC-JP>

$ ruby19 -e '#-*- encoding:utf-8 -*-' -e 'p __ENCODING__'
#<Encoding:UTF-8>

Therefore no differences if the file has the magic comment.

-- 
Nobu Nakada