If you enter words with non ASCII characters in the new search, those non ASCII characters are interpreted strangely, and the search doesn't work as expected. It makes the new search system uneffective for no English speaking residents. I tested this issue in detail using 1.18.6(2) RC viewer. I believe it is in 1.18.5 viewers, although I have not examined. I also believe that this issue is same as SVC-1020. I'm filing this separate issue because I think filing it under VWR project attracts more appropriate developers in LL. REPRODUCTION Start the 1.18.6.2 viewer and login. Type a word that contain non ASCII characters, e.g., "Français". OBSERVED BEHAVIOUR The non ASCII character ("ç" in this case) is translated into six hexadecimal digits, and the searcch returns no hits. (See figure "Francais-NG.png".) EXPECTED BEHAVIOUR The non ASCII character is handled as-is and some hits are returned. (See figure "Francais-OK.png".) Note that the screen shot "Francais-OK.png" is taken on a viewer after applying the attached patch. See SVC-1020 for other test cases and discussion. TECHNICAL DETAILS The cause of this bug is the way SL viewer creates URLs containing non ASCII characters. Including non ASCII characters in URL parameters requires each UTF-8 byte be written as two hexadecimal digits preceeded by a '%', SL viewer fails to do so. It passes UTF-8 bytes represented as a C++ signed char data to general purpose formatting function, so sign-extension occurs. As a result, six extra F's are put after the '%'. For example, "ç" in the example above is C3 A7 in UTF-8, and it should be written as %C3%A7 in URL. However, the current SL viewer make it as %FFFFFFC3%FFFFFFA7. Simply casting each byte to unsigned char (or U8 in LL dialect) solves the issue. The attached patch is essentially the same thing as ones attached to SVC-1020 (written by march Korda). I just stripped the patch to the minimum lines. (Although the change to lluri.cpp is not strictly necessary to fix this search issue.)