Forums Bug Reports mIRC 7.1 bug

Any workaround will ultimately be a hack.

Ideally mIRC should NOT be encoding the TARGET portion of any IRC command, as this violates the IRC protocol (a target is a unique 8bit encoded space and comma delimited identifier and must be represented exactly in its original form). Of course, it's fairly difficult to differentiate what part of a command is a target and how it should be re-encoded given that the destination encoding is unknown unless the specific target was listed by the server. Basic joining/parting and messaging might work (because mIRC knows the original target's bytestring), but scripts would still not work. For instance, "/msg # hello" could not work because the # result will be encoded as utf-8 in the script. There's no real way to support this unless by re-adding codepage support, or a much more complex/comprehensive encoding layer, which Khaled has stated is extremely unlikely to happen. Without script support, the basic functionality isn't really worth supporting. Many users will still complain that "my script does not work in #CHANNELNAME", and the problem will continue to persist until they're on a utf-8 channel, so this isn't exactly a solution. All that work in supporting codepaged channels just to tell users to use utf-8 to get a proper IRC experience anyway? Doesn't seem worth it to me.

A much better long-term strategy is indeed to migrate people over to UTF-8, which is why, although subversive and sneaky, I think this might be a good idea. Khaled outlined this strategy in this post, and you should probably read it to understand where he stands on this issue. Most clients are already using utf-8 anyway, so mIRC is not really alone. I'd bet that a good 80% of the users in these codepaged channels are on some version of mIRC, so this is actually not an issue of there being other clients out there to deal with, but rather the fact that most other client already handle UTF-8 and mIRC 6.x was lagging behind. And indeed, the results on Undernet support this:



Frankly, servers can do a lot to help people in this process by redirecting them to utf-8, but server implementors tend to be uninterested in moving this process along. In fact, you can read the beta threads regarding unicode to find an exchange between a server implementor about how "encoding support" is meant to be the client's responsibility, not the server's. Note that this goes against your previous post that "encoding should be handled by the server", and therein lies the vicious cycle. Server developers think it's the client's responsibility, client developers think it's the server's responsibility. mIRC is taking the step in trying to settle the dispute once and for all by sticking to a specific implementation.