View Single Post
Old 10th October 2007, 19:48   #4
Senior Member
Pidgeot's Avatar
Join Date: Jan 2002
Location: Denmark
Posts: 136
I've tracked down the search bug myself, with a little experimenting. It's IE that causes the error, but it's still a bug in Winamp/Bento.

Using Fiddler, I tried to accessメインページ (Japanese Wikipedia Main Page) and¸&action=edit (editing of that page) directly using IE. The former works, but the latter doesn't.

It looks like ShDocVw doesn't convert querystrings to UTF-8, unlike the path and filename parts of the URI - likely since there's no way of knowing what character set the client is running; only file names have a more or less standardized character set. Instead, it assumes the system character set when processing the URI. This means the ideographic space is converted to the nearest ANSI equivalent, which is a regular space. However, it doesn't perform URL encoding, meaning the request is cut off due to a rogue space.

The ????? shown in the Bento browser appears to come as a result of a redirect issued by the search page it calls (I take it it's due to some logging or something that shows the request was sent from Winamp). Since the string has already been corrupted, the redirect will of course be corrupted as well.

While you could argue that not URL encoding the converted string is a bug, it's probably because they couldn't make it submit the right request otherwise - if you manually typed it in, you'd have to replace a space with a plus, but if it's already been URL encoded, that plus would be replaced by %2B, resulting in a different request.

In other words, the fix is to convert the searchstring to the character set expected by the receiving end (UTF-8, in this case), and then URL encoding that before adding it to the URI.

That just leaves the peculiar font drawing oddity that stretches the kanji characters in the navigation edit controls, then - I've no idea what might cause that to happen, though.
Pidgeot is offline   Reply With Quote