Can you please try with the latest 3.2.36 pre-release: http:// d.udm.net /bar/~bar/mnogosearch-3.2.36.tar.gz We’ve fixed several problems in GroupBySite recently. Perhaps your problem will disappear.

To complicate things, this behavior does _not_ occur if there is
anything in the “URL matches” field. Adding a hidden field to the
simple form, named ul with value % gives me the results I would expect.

On Mon, 19 Dec 2005, Tom Allen wrote:

When the option GroupBySite is selected, there are sites repeated in the
search results, with the same site_id. According to the documentation,
this should not be the case, correct? I am using 3.2.31-1 from debian,
although I also get the same result with the search.cgi from 3.2.35. Is
this a known bug? I can put up a demonstration link if it would help
someone explain to me why this happens. Did I miss a configuration
option or something?

Udm_Set_Agent_Param($this->udmAgent, UDM_PARAM_BROWSER_CHARSET, 'UTF-8');

I.e. mnoGoSearch considered the query to be in latin1, not in utf-8.

Hi again,

(...)
> The reason seems to be with wrong character_set_results, character_set_connection and
> character_set_client setting. It should utf8.
(...)

ok, that’s done:

+————————–+—————————-+
| Variable_name | Value |
+————————–+—————————-+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+————————–+—————————-+

(...)
> Then, configure indexer and search.cgi this way:
>
> DBAddr mysql://user:passwd@host/dbname/?MyCnfGroup=client
(...)

done as well.

(...)
> That should fix the problem.
(...)

Unfortunately, it does not fix the problem. With the search.cgi it works, when connecting via php, it does not.

When submitting the query, we set the charset to utf-8. As long as we search for word without special chars, we get the results.

Strange, though, it seems like the results are not valid xhtml-compliant utf-8 - they sometimes contain latin-1-chars, sometimes special charcodes like ascii #4.

When seaching for word that contain special chars, it looks like the submitted word (which is utf-8) is being split and the searcher goes for these “two words”. The split happens after the special char.

We then tried to transform the search string with urlencode, but then even nothing is found.

The main thing we don’t get sorted out (obviously) is the difference in the behavior of search.cgi and the php functions.

Does the search.cgi do any ‘magic’ encoding/recoding/transformation of charsets?

What else would help for an analysis?

Reply: <http://www.mnogosearch.org/board/message.php?id=17130>