hi-world cup

More info on this. I've used LiveHeaders (plugin for Firefox) to see what's exactly sent to the server. This is part of what's sent to the server (request body):

=ok&value=Desinfecci%C3%B3n%20del%20sistema%0A&_=

And when I send the same string from an input field using and standard form (but also post method):

action=edit&id=0&diagnostico=Desinfecci%F3n+del+sistema&horas=

The encoding is clearly not the same. I'm no expert of character enconding but I hope someone can help on this.

Ajax.InPlaceEditor calls Form.serialize() from Prototype internally to serialize the dynamically created form. This function uses the JavaScript function encodeURIComponent() to encode URI components, which works by encoding the provided string (in this case the value of the text field) with UTF-8 escape sequences.

Because JavaScript provides no way to encode to arbitrary encodings, using UTF-8 (which is the de facto standard for multi-language pages) is the only "easy" way to go here. If you have to use ISO-8859-1, you can manually change prototype.js to use escape() instead of encodeURIComponent().

See http://xkr.us/articles/javascript/encode-compare/ for some additional information.

Surely is good enough, the only problem was I was excepting to use the same encoding as my page. No problem if you know it.

I've updated the scriptaculous wiki to reflect this.

Thanks for your response.

If you don't mind this kind of hack, just do this in your Javascript:

encodeURIComponent = escape;

Changing the "encodeURIComponent" JavaScript function to "escape" did not work for me, which figures, as the documentation states they both return the data in UTF-8.

The solution that worked for me is to add a before_filter to convert all strings in the params hash of an AJAX request from UTF-8 to your default encoding: (taken from http://dema.ruby.com.br/articles/2005/07/22/playing-nice-with-ajax-and-iso-8859-1)

require 'iconv' class ApplicationController < ActionController::Base

before_filter :convert_xhr

ICONV = Iconv.new('ISO-8859-1', 'UTF-8')

def convert_xhr

convert_hash(params) if request.xhr?

end

def convert_hash(hash)

for k, v in hash

case v when String: hash[k] = ICONV.iconv(v) when Array: hash[k] = v.collect { |v| ICONV.iconv(v) } when Hash: convert_hash(v) end

end

end

I am re-opening this defect because it basically means that all AJAX functionality (auto_complete_for, in-place-editing, etc) will not function properly if you use foreign encodings (such as windows-1255 for Hebrew, which is what I used). Since Rails and Ruby do not do much in the way of Unicode support (yet), I think it is reasonable to expect Rails to convert strings from AJAX requests to its default US-ASCII encoding (or whatever encoding is specified in config/enviroment.rb), and consider it a bug when it does not.

Replying to omerraviv@gmail.com:

Since Rails and Ruby do not do much in the way of Unicode support (yet), I think it is reasonable to expect Rails to convert strings from AJAX requests to its default US-ASCII encoding

I don't think it's going to happen. Even if it does, this isn't a defect of Prototype framework. Closed.