# Unicode hacks - fixes for webrick and Safari

**URL:** <https://www.ruby-forum.com/t/unicode-hacks-fixes-for-webrick-and-safari/90714>\
**Category:** Rails\
**Created:** [January 5, 2006, 5:44pm UTC](https://www.ruby-forum.com/t/unicode-hacks-fixes-for-webrick-and-safari/90714 "2006-01-05T17:44:40Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Izidor\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/ee59a6/32.png) [@Izidor\_J](https://www.ruby-forum.com/u/Izidor_J)\
**Post date:** [January 5, 2006, 5:44pm UTC](https://www.ruby-forum.com/t/unicode-hacks-fixes-for-webrick-and-safari/90714/1 "2006-01-05T17:44:40Z")

</div>

Hello!

First, thank you Julian for the useful plugin ‘unicode\_hacks’ \<  
[http://julik.textdriven.com/svn/tools/rails\_plugins/unicode\_hacks/](http://julik.textdriven.com/svn/tools/rails_plugins/unicode_hacks/)\>.

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.

---

<div class="post-metadata">

**Author:** ![Izidor\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/ee59a6/32.png) [@Izidor\_J](https://www.ruby-forum.com/u/Izidor_J)\
**Post date:** [January 5, 2006, 9:48pm UTC](https://www.ruby-forum.com/t/unicode-hacks-fixes-for-webrick-and-safari/90714/2 "2006-01-05T21:48:40Z")

</div>

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