User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050404 Firefox/1.0+ Build Identifier: Camino 2006042704 (1.0.1int) When making new plugins for the search engines toolbar (by editing SearchURLList.plist or using CamiTools), some do not work because of a mismatch in the charset: Non-Ascii characters in the search variable %s are always encoded in utf-8 (and then urlencoded) by Camino. Some search engines however use other charsets, such as iso-8859-1. As a result, the search engine gets the wrong search term. It would be nice to have some sort of syntax to specify the charset for the variables submitted to the search engines (such as %s:iso-8859-1, for example...) Reproducible: Always Steps to Reproduce: 1.Edit SearchURLList.plist 2.For example, make an entry for the search engine wrapper "Lexiquo", which uses iso8859-1 as its charset: http://www.lexiquo.net/lexiquo_result_deu.html?DEU&Keine&pro&%s&google 3. Search for a term with a special char in it, such as "Theater München" Actual Results: As you can see in the pre-filled search field of the engine, the above search terms have transcoding errors: "Theater München". The results are different than those you will get if you enter the search term directly into the search engine. Expected Results: The search term field should show "Theater München" like I typed in the quick search field in Camino

See also the discussion in bug 307620 about bookmark keyword searches (which are essentially the same as the search engine strings).

What we probably ought to do, instead of UTF-encoding non-ASCII characters, is %-encode them. That *should* do it, although I don't know what impact this might have on IDNs. cl

Or we should hook up to what Sm and Fx do; see bug 258223.

I think Gecko is doing UTF-8 for a reason, too.

(In reply to comment #2) > What we probably ought to do, instead of UTF-encoding non-ASCII characters, is > %-encode them. I don't follow. UTF defines what numeric values corresponds to what characters. URL escaping is a way of representing characters as numeric values rather than in raw form, so that the string is valid ASCII. They are different concepts (and in fact, both are used simultaneously).

Does this still matter in the new, OpenSearch world?

(In reply to comment #6) > Does this still matter in the new, OpenSearch world? Yes, unfortunately the new WebSearchEngines.plist ultimately still does encode the URL and search token using the same method, just in a different dictionary key schema.