Search results to passive users get sent to UTF-8 nick
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| DC++ |
Confirmed
|
Low
|
Unassigned | ||
| LinuxDC++ |
Confirmed
|
High
|
Unassigned | ||
Bug Description
The search results that LinuxDC++ sends to a passive user with accented characters in their nick do not arrive, as far as I can tell it's because the nick they are sent to is in UTF-8, but this is an NMDC hub using CP1252 encoding. The results are sent to the hub, but the hub does not send them on, probably because it can't find that user.
LinuxDC++'s own nick also has an accented character, it is correctly in CP1252 encoding in the search results.
Nicks used were "éjs" and "tëst_ldc" (these clients are only used for testing).
The patch fixes it for me, by converting the nick from UTF-8 to the hub's encoding.
This is with LinuxDC++ 0.698 bzr dated 20081212 / rev 281.
It also affects DC++ 0.7091, at least when running under wine.
OS is Fedora 10, using en_GB.UTF-8.
| Edward Sheldrake (ejs1920) wrote | #1 |
| Steven Sheehy (steven-sheehy) wrote | #2 |
| Changed in linuxdcpp: | |
| importance: | Undecided → High |
| status: | New → Confirmed |
| Jacek Sieka (arnetheduck) wrote | #3 |
| Changed in dcplusplus: | |
| importance: | Undecided → Low |
| status: | New → Confirmed |
| tags: | added: core |
I can confirm this. Your fix looks correct with how the code is setup right now. It would be nicer if we didn't have to convert from hub encoding -> UTF-8 -> hub encoding since the conversions can be lossly in some cases (e.g. if wrong hub encoding is chosen, user sends different encoding than hub, etc), but that would be a lot of work to implement. Forwarding to upstream.