Forums Bug Reports mIRC 7.1 bug

i am french ^^

#infométéo (1 pseudo) mIRC 7.1 #infométéo

#infométéo (10 pseudo) mIRC 6.xx #infométéo

non bug é = é

bonne journée

[X] BUG F12 inviter => #xxxxx <= mIRC 7.1

é = é

Please see this thread. Any channels or servers that use only code page support and not UTF8 support will have issues until they start supporting UTF8. You will have to stick to 6.35 until support for UTF8 is added to those channels and/or servers. The main reason to upgrade to mIRC 7.1 is for unicode support and if you aren't going to use it, there's not much reason to upgrade anyhow.

Hi,

I would call the font-handling in mirc 7 a very big bug, too. I never thought that mirc would leave the beta status without handling code-pages in existing irc-networks correctly.

In european irc networks we use many channels that uses language specific characters. What mirc now does is receiving channel-names containing fonts like é or ö by the ircd, but it sends out this fonts coded in uft-8.

That could result in many problems and I am not sure if this is a security issue - sending out messages to wrong channels or nicknames.

In my opinion this is a very big mistake. Migrating to utf-8 should be the part of the ircd's, but not of a client. The client has to handle every input in a consistent way.

Think about a webbrowser that can only handle utf-8 and nothing else. Noone would use it!

That's the same what we can answer in our support-channels - do not use mirc 7.1 at the moment, there is no way to join channels that exists since 10yrs.

Khaled has been pretty specific that he is not going to support code pages any longer and that mIRC will be entirely unicode. Whether he adds an option to send text without encoding it, that's another issue. He might allow something like that which would make it easy to script your own code page support. In any event, unicode has been around for at least a decade. There is really no reason why people haven't made the effort to support it at this point, imo. Especially considering it gives you a *single* encoding that works for everyone in the world without needing to change code pages over and over to talk to different people in different channels on different networks... etc. Why wouldn't people want to go that route? Yes, it takes work, but Khaled pulled it off. Others can as well.

Hi Riamus2,

the problem is, that the users do not understand what happend! User (a) using 6.xx invites a user (b) using 7.xx into a channel and he joins a complete different. That's weird.

Using svsjoin (with a 6.xx-client) I can join myself using a 7.xx-client into a "codepage-channel". So I receive every privmsg, but are unable to answer.

Tha same thing happend with users who use a join-list with nickserv.

You see, mirc 7.xx is completly inconsistent. No normal user understands what happend. Thats the problem

problem mIRC 7.1


mIRC 6.35 => mIRC 7.1

http://a.imageshack.us/img576/5302/mirc2.png

----------------------------

mIRC 7.1 => mIRC 6.35

http://a.imageshack.us/img576/1227/mirc3.png

http://fr.wikipedia.org/wiki/UTF-8

http://fr.wikipedia.org/wiki/ISO_8859-15

firefox 3.6.8 version => UTF-8

UTF-8 => é

iso-8859-15 => é

very big !

windows vista SP2

This looks correct. mIRC v7.1 is displaying the Unicode representation of all of the characters. mIRC v6.35 could not do that because it was not a Unicode application.

This is one of the reasons why mIRC was converted to Unicode, so that the interface would correctly display characters from all languages, instead of displaying the literal UTF-8 encoded text, which is unreadable.

All text in mIRC is now stored as Unicode and is converted to UTF-8 when it is sent to the server. Likewise, when mIRC receives UTF-8 text from the server, it is converted to Unicode.

Hi,

ok, reading this and some other threads I can summerize:

1. mIRC v7.xx is unusable if the user is oper or admin in a network. Thats why the user has no chance to handle other users or attacts that uses channel-names containing codepage-characters. In this scenario I assume that nicknames must not containing other characters than the allowed ascii-characters.

It would work if mirc does not converts incoming channels to utf8.

2. mirc v7.xx is unusable for normal users. Using nickserv's autojoin-feature it is possible to have a situation like

TC on #ÖSF @#ÖSF (mIRC 6.35)
TC on #&#1363;F @#ÖSF (mIRC 7.1 ) (the special char seems to have the code 0x553)

Now I close the #ÖSF-Channel in v7 using the [x] button. In the channel-list no #ÖSF is listed, but in the whois I see

TC on #ÖSF

So I have joined a channel but mirc does not show me - this is evil.

mIRC v7.xx has no chance to handle this correctly, no user without knowlege of character encoding has a chance to understand what happens.

Using mirc 7 I (in my position of a netadmin) have no chance to leave this channel, there is no way to use svspart, kick, nothing.

Khaled, do not misunderstand me. I am a friend of going forward, so utf-8 / unicode is the right way. But today it is out of the question to use a client that can handle only utf-8.

Agreed totaly. thats evil i cant even join my room lol thought it was dropped blah!
Well i rather back to older mirc or use another client but this is kinda annoys me ermm
Hope things will be sorted.

Hi xyzzy,

the most users who chat only in their few channels have no problem with mirc 7, because the parser understands privmsgs sent in iso-charset. So the user can read the normal special characters like é or ü.

But opers or admins like me must have the possibility to join every channel existing in their networks. We are not in the position to ban users that cannot use unicode.

But if they use clients with iso-charset, we cannot use mirc 7 that acts completly inconsistent with existing servers.

This is why mIRC has basic support for accessing these channels with /raw -n

As much as you'd probably like to see codepage support, you probably won't see it in 7.x and onwards. mIRC will get better at allowing scripters to implement their own codepage support, though-- /raw -n is the first step in this process.

have a problem with CYRILLIC support not read how to fix ?
and where is this speech support and how to use ?
and maybe in next version add video support ?
it`s time to evolution for mIRC with include audio and video support for astrix servers and other methods p2p or other
Thank You

On my keyboard is also Ä Ö Ü keep the 6.35. I am German and the ä ö ü are in our standard. Please I let it be takes ö me in again æ ü or wait until 4.X outside is unreal because man Yes can (...) scheme change the 7.1 unacceptable is me. My provider has yet self not moving to ipv6.

Sorry fpr my language

You do realize that Unicode does not mean international characters stop working, right?

In fact, the reason mIRC adopted unicode was for the exact opposite reason-- to improve support for multiple languages. Ä Ö Ü æ, and all characters continue to work in 7.x. The only difference is that when you type them, they are sent as UTF-8, pretty much a worldwide standard encoding to represent your text. 6.35 can display Unicode, so they should be able to see what you wrote (though it might require enable UTF-8 support).

If you tell your friends to also enable UTF-8 messaging, you will see what they are writing too.

Cyrillic still works. As for the other questions, this topic is not the right place to get help, try the mIRC Help forum for questions about new features.

This won't work. Since I have around of 10 different script that are programmed not to interfer each other, I have to change every of this script. And I think it would be the same with other users.

You are correct if you say, we can use raw -n to send iso-characters. But and event in any script must be catched and translated to own script that uses iso-characters. And in situations without user-interaction (i.e. the autojoin-list in many nickserv-implementations), I have no chance to detect the charset.

The only way to solve this would be a kind of low-level-events that cannot be overridden and used to translate between the charsets. But this translation should be the part of the client, not of any user-script.

As I said before, if it is possible to create an inconsistent state, the client has an error - not the user or the server. Nettalk for example hides any iso-channels when I enables utf-8-support. That's not what I excpect, but it's better than an inconsistent state and - that's the point - I have the choice to enable or disable it.

The fact that you will need to update your scripts does not mean "it will not work". Updating scripts to work with 7.1 was entirely expected and documented during the betas. I don't see having to update your scripts as a blocker in itself.



We're not talking about full compatibility for chatting purposes. Your concern was that an admin was unable to properly manage a server. /raw -n allows you to send commands to manage a server. As I already mentioned, improved scriptability will likely come in future versions, but this is a fine start.



I'm not too sure what you mean by this, or why this is the only solution. This also is starting to sound more like a feature suggestion than a bug report.



Define inconsistent state. I don't see mIRC introducing inconsistent state here. There is an inconsistency in the way mIRC data from the server, but the state itself is fine. mIRC joins a utf-8 encoded channel-- the problem is that it joins the wrong channel, not that the state is inconsistent. If you'd like, mIRC could hide these channels, but this is beside the OP's point. The issue is about getting mIRC to communicate with the ANSI-encoded channel, not about whether the channel should be listed.