From: Michael Selig Date: 2008-10-27T07:28:42+09:00 Subject: [ruby-core:19525] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) On Sun, 26 Oct 2008 23:34:26 +1100, Nobuyoshi Nakada wrote: >> > I'd prefer to default the internal encoding to the source >> > encoding of the main script. >> >> But then how do you tell Ruby NOT to set "default_internal"? > > I think defaulting the internal encoding to something other is > bad. Yes you are right, and I was not suggesting doing that. But Matz wants to default default_internal to nil. With your proposal, how do you do that and still set the source encoding? My original suggestion was to use an extended "magic comment" to set both. I still think that is the best way! >> It also means that comments must be in the default_internal encoding >> (see >> your comment below). > > I don't follow you here, all comments should be written in the > source encoding. Why default_internal affects? I thought one of your points was that you would like to be able to write Japanese (or other non-ascii) comments which is otherwise only ascii (which may use "\u" in literals, and want default_internal to be UTF-8). This means that the source encoding should be Japanese. Your suggestion of defaulting default_internal to the source encoding means that it will be set to Japanese. I am not sure that this is always desirable. (This is very minor - you can always override it) >> > Therefore no differences if the file has the magic comment. >> >> That's true, but my point was "why should a simple non-m17n non-ascii >> ruby >> program have to contain the magic comment"? > > Because, non-ascii. It's definitely enough reason. Isn't backward compatibility with 1.8 scripts more important? You are now forcing anyone with 1.8 scripts containing non-ascii string literals to put in a magic comment, otherwise you get "inavlid multibyte char (US-ASCII)" error in 1.9. Cheers Mike