Any ircd should support UTF-8 since UTF-8 is completely compatible with the IRC protocol. The only way the ircd would be incompatible with UTF-8 is if it went out of its way to do stupid things like re-encode your text into cp1251 without asking. AFAIK, the Russian networks I've been to have had server-side settings for this transcoding and it can be turned off, so it's not actually a problem.

The problems with the ircd "not" supporting UTF-8 that you are likely referring to are not to do with the ircd, but rather with the way users are naming channels on the network. This is not an ircd issue but rather a problem with any scenario where clients using different encodings try to communicate with each other. Because the IRC protocol specifically does not enforce any transcoding, all data is treated as binary bytes, and because of this, a utf-8 encoded channel name won't match up with a cp1251 encoded one. This isn't an mIRC specific problem. The only way to solve this problem in a consistent fashion across all IRC clients is for the ircd to become aware of the client encoding and transcode all data in and out. If your desire for change was pointed in the direction of ircd maintainers rather than IRC clients, this problem would be solved a lot more quickly-- especially since updating servers to be encoding aware would make encoding problems disappear for every client, not just mIRC-- and it would require no users to change their client software. This is a much more effective solution than petitioning every single IRC client to support old encoding formats.

I should point out that most IRC clients in existence right now handle UTF-8-- the vast majority of them actually deal only in UTF-8. So really, the only problem here is users who are refusing to upgrade to latest technology. You'll find that if you stop fighting against the change and upgrade (and tell your friends), the problem will magically go away. Adding support for cp1251 into a new mIRC would just prolong the inevitable.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"