Forum: Ruby on Rails unicode hacks - fixes for webrick and Safari

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Izidor J. (Guest)
on 2006-01-05 18:44
(Received via mailing list)
Hello!

First, thank you Julian for the useful plugin 'unicode_hacks' <
http://julik.textdriven.com/svn/tools/rails_plugin....

I have found some problems running my app in development on Webrick
and looking at it with Safari (MacOS X 10.4.3,  Safari 2.0.2). Some
files are sent with different sizes (e.g. default css example, or
controls.js ), and it causes long delays for each request.

When I changed KCODE to 'none', everything worked OK. It seems that
string overloading borks something in Webrick internally.

My solution is to set KCODE in before/after filters, so that webrick
code is not affected. There is some Rails code run before/after the
filters, so it is not completely fullproof solution. Maybe some Rails
code which runs before/after filters would need Unicode string
processing - it doesn't seem likely to me, but you never know.

I have modified file actionpack_filters.rb, where I added the
following private methods:

     def set_kcode_utf8
       @old_kcode = $KCODE
       $KCODE = 'u'
     end

     def restore_kcode
       $KCODE = @old_kcode
     end

and added these two as filters in init.rb:

Object::ActionController::Base.send(:before_filter, :set_kcode_utf8)
Object::ActionController::Base.send(:after_filter, :restore_kcode)


Additionally, I have modified the safari fix, so that it re-encodes
the entities only for Safari version less than 1.3. Instead of
original condition I propose this one:

       if @request.xhr? and @request.env['HTTP_USER_AGENT'] =~ /
AppleWebKit\/(\d+)/ and $1.to_i < 312


Julian, if you want to include these solutions into your plugin, feel
free to do so....

Regards,
Izidor J.
Izidor J. (Guest)
on 2006-01-05 22:48
(Received via mailing list)
Well, after playing a bit with this plugin, I have concluded that it
is rather too risky for me. Overwriting the String#size and
String#slice causes too much potential problems, as seen in my
Webrick problems....

Besides, database encodings are now supported via configuration
setting. The only thing that is needed is Safari support, if you
expect your users to be on Jaguar, and setting headers.

Since I have the luxury of ignoring Jaguars, and header setting is
one-liner in ApplicationController, I don't need this plugin.

I would recommend that anybody using it thinks hard about potential
problems, since String#slice is used in such strange places as
database adapters where it can cause real trouble with appropriate
binary data...

I guess that there is no easy way to support Unicode until every
String knows its encoding. In Ruby 2.0... Right now, only the hard
ways are available...

izidor
This topic is locked and can not be replied to.