131498 - Can't join a channel with Japanese name

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Koike Kazuhiko]

Can't join a channel with Japanese name.
But RFC1459 allows Japanese channel name.

http://www.rfc.net/rfc1459.html
1.3 Channels
****************************************
Channels names are strings (beginning with a '&' or '#' character) of
length up to 200 characters.  Apart from the the requirement that the
first character being either '&' or '#'; the only restriction on a
channel name is that it may not contain any spaces (' '), a control G
(^G or ASCII 7), or a comma (',' which is used as a list item
separator by the protocol).
****************************************

Comment 1

[Koike Kazuhiko]

Attachment: patch

This patch converts channel name string from Unicode before sending
"JOIN" and "MODE" and to Unicode after receiving the responses for them.

Comment 2

[Koike Kazuhiko]

The patch has two problems.

(1) 
  name = fromUnicode(name.toLowerCase() + " ");
  e.channel = e.server.addChannel (name);

This blank is necessary to avoid bug 114923.


(2)
function ucConvertIncomingMessage (e)
{
  if (e.code != "JOIN")
  {
    e.meat = toUnicode(e.meat);
  }
  return true;
}

This conditional statement should be placed somewhere else.

Comment 3

[Koike Kazuhiko]

Attachment: patch v2

Comment 4

[Koike Kazuhiko]

*** Bug 131888 has been marked as a duplicate of this bug. ***

Comment 5

[Koike Kazuhiko]

Attachment: patch v3

patch v2(attachment 76553 [details] [diff] [review]) isn't case insensitive.

Comment 6

[Koike Kazuhiko]

rginda, could you review the patch?

This bug is very important for Japanese IRC users.

Comment 7

[Koike Kazuhiko]

Attachment: patch v4

Converts reply strings of /list command.

Comment 8

[Koike Kazuhiko]

Attachment: patch v5

Comment 9

[NAITOH Jun]

Attachment: patch v6

patch v5 has a bug in handling irc:// multibyte language encoding.
This patch fixed it, so that makes patch v5 useless.
(and this patch is include attachment 84546 [details] [diff] [review].
by http://bugzilla.mozilla.org/show_bug.cgi?id=146058)

This bug is very, very important for Japanese IRC users.
Please review.
If this bug don't fixed, Japanese can't use chatzilla.

Comment 10

[Robert Ginda]

+    var encodedMatchText = fromUnicode(matchText + " ");
+    /* bug 114923 */
+    encodedMatchText = encodedMatchText.substr(0,encodedMatchText.length -1);
+

fromUnicode() resets the .charset of the decoder, which is supposed to work
around bug 114923.  Do we still need to append the empty space for some reason?

-            unescape(ary[1]).toLowerCase().replace("\n", "\\n"): "";
+            unescape(ary[1]).replace("\n", "\\n"): "";

Why aren't we lowercasing anymore, won't this cause problems elsewhere?  It
seems to me this will cause irc://irc.mozilla.org/Mozilla and
irc://irc.mozilla.org/MOZILLA to create two distinct channel tabs.

+        case "IRCChannel":
+            name = source.unicodeName;

Is it possible to have an encoded nickname too?

-               sourceObj ? sourceObj.name : this.name]);
+               sourceObj ? sourceObj.unicodeName : this.unicodeName]);

sourceObj could be a network or user object, which don't have a unicodeName
property.    I'm worried here that you're making new assumptions that the
current object will have a "unicodeName" property.  In many places, sourceObj or
currentObject can be an irc network, server, user, channel, or even the client
object itself.

+    var encodedName = fromUnicode(name + " ");
+    /* bug 114923 */
+    encodedName = encodedName.substr(0,encodedName.length -1);

again, doesn't toUnicode take care of bug 114923?

Comment 11

[NAITOH Jun]

>+    var encodedMatchText = fromUnicode(matchText + " ");
>+    /* bug 114923 */
>+    encodedMatchText = encodedMatchText.substr(0,encodedMatchText.length -1);
>
>fromUnicode() resets the .charset of the decoder, which is supposed to work
>around bug 114923.  Do we still need to append the empty space for some reason?

Yes! If I don't append the empty space, fromUnicode() is useless on ISO-2022-JP
decode.
If I don't append the empty space, fromUnicode() isn't  append the ISO-2022-JP
end code "ESC ) B", now.
This is very important ploblem.
All ISO-2022-JP's channel name is a channel name including an end code.
If it doesn't include end code, it will become another channel name,
so I can not join in the target channel.
The empty space is added in order to avoid this bug, and one character
equivalent to an empty space is deleted from the changed character sequence.

But this is add-hoc. (Originally, we should correct bug 114923.)


>-            unescape(ary[1]).toLowerCase().replace("\n", "\\n"): "";
>+            unescape(ary[1]).replace("\n", "\\n"): "";
>
>Why aren't we lowercasing anymore, won't this cause problems elsewhere?  It
>seems to me this will cause irc://irc.mozilla.org/Mozilla and
>irc://irc.mozilla.org/MOZILLA to create two distinct channel tabs.

This is no ploblem.
Because It is because same processing is performed by CIRCChannel() function.
It doesn't seems to me two distinct channel tabs.

This patch is three information on "channel name", is hold.

"unicodeName" is for a display.
"encodedName" for communication of an IRC client and a server.
"name" for the judgment of being the same channel.

Please don't send lowercasing channel name to IRC server.
If you send lowercasing channel name and other IRC user type /list case, the
channel name can not decoded.
Because , the channel name is lowercasing.

>+        case "IRCChannel":
>+            name = source.unicodeName;
>
>Is it possible to have an encoded nickname too?

This isn't nickname, but this is channel name.
CIRCChannel object has unicodeName property.

>-               sourceObj ? sourceObj.name : this.name]);
>+               sourceObj ? sourceObj.unicodeName : this.unicodeName]);
>
>sourceObj could be a network or user object, which don't have a unicodeName
>property.    I'm worried here that you're making new assumptions that the
>current object will have a "unicodeName" property.  In many places, sourceObj or
>currentObject can be an irc network, server, user, channel, or even the client
>object itself.

Sorry, this is a mistake.
I should have processed as follows.
--------------------------------
    if (fromUser)
    {
        statusString =
            getMsg("cli_statusString", [d.getMonth() + 1, d.getDate(),
                                        d.getHours(), mins,
                                        sourceObj.nick + "!" + 
                                        sourceObj.name + "@" + sourceObj.host]);    
    }
    else if (this.TYPE.search(/IRCChannel/) != -1)
    {
        statusString =
            getMsg("cli_statusString", [d.getMonth() + 1, d.getDate(),
                      d.getHours(), mins,
                      sourceObj ? sourceObj.unicodeName : this.unicodeName]);
    }
    else
    {
        statusString =
            getMsg("cli_statusString", [d.getMonth() + 1, d.getDate(),
                      d.getHours(), mins,
                      sourceObj ? sourceObj.name : this.name]);
    }
--------------------------------

>+    var encodedName = fromUnicode(name + " ");
>+    /* bug 114923 */
>+    encodedName = encodedName.substr(0,encodedName.length -1);
>
>again, doesn't toUnicode take care of bug 114923?

The influence of bug 114923 is a problem very serious in Japanese (ISO-2022-JP).
If I don't append the empty space, fromUnicode() isn't  append the ISO-2022-JP
end code "ESC ) B", now.

Comment 12

[Robert Ginda]

> If I don't append the empty space, fromUnicode() isn't  append the ISO-2022-JP
> end code "ESC ) B", now.

Oh, I think I understand.  The convention is that the end-escape code is part of
an encoded channel name?

>>Is it possible to have an encoded nickname too?
>
> This isn't nickname, but this is channel name.
> CIRCChannel object has unicodeName property.

Yes, I understand that.  My question was whether or not it is possible to have
an endcoded nickname too.  If so, perhaps we should file a new bug to the
ability to handle encoded nicknames.

>  else if (this.TYPE.search(/IRCChannel/) != -1)

I'd prefer |this.TYPE == "IRCChannel"|, because it is more specific, and easier
to read.

Please attach an updated patch with your latest change.  I will create an XPI
and post it to <http://www.hacksrus.com/~ginda/chatzilla/> for testing.

Comment 13

[NAITOH Jun]

Attachment: patch v7 for ChatZilla 0.8.8

>> If I don't append the empty space, fromUnicode() isn't  append the
ISO-2022-JP
>> end code "ESC ) B", now.
>
>Oh, I think I understand.  The convention is that the end-escape code is part
of
>an encoded channel name?

Yes , this is not IRC rule, but this is ISO-2022-JP rule.
"At the end of the sentence, it returns to the original state."

>>>Is it possible to have an encoded nickname too?
>>
>> This isn't nickname, but this is channel name.
>> CIRCChannel object has unicodeName property.
>
>Yes, I understand that.  My question was whether or not it is possible to have

>an endcoded nickname too.  If so, perhaps we should file a new bug to the
>ability to handle encoded nicknames.

Oh, I was mistaken in the interpretation. Sorry.

Unfortunately I can not use Japanses (encoded) nickname.
The character which can be used for nickname is only as follows.

Please check RFC2812.
ftp://ftp.isi.edu/in-notes/rfc2812.txt

  nickname   =	( letter / special ) *8( letter / digit / special / "-" )
  letter     =	%x41-5A / %x61-7A	; A-Z / a-z
  digit      =	%x30-39 		; 0-9
  special    =	%x5B-60 / %x7B-7D
		   ; "[", "]", "\", "`", "_", "^", "{", "|", "}"

but, it will be glad if a capital letter small letter can be used.

>>  else if (this.TYPE.search(/IRCChannel/) != -1)
>
>I'd prefer |this.TYPE == "IRCChannel"|, because it is more specific, and
easier
>to read.

OK.

>Please attach an updated patch with your latest change.  I will create an XPI
>and post it to <http://www.hacksrus.com/~ginda/chatzilla/> for testing.

OK.
It was reflected with this patch.
I expect. Thank you.

(P.S. this patch is include attachment 84546 [details] [diff] [review].
by http://bugzilla.mozilla.org/show_bug.cgi?id=146058)

Comment 14

[Robert Ginda]

I've posted an XPI with your changes to <http://www.hacksrus.com/~ginda/chatzilla/>.

Comment 15

[NAITOH Jun]

Attachment: "Open at Startup" patch for ChatZilla 0.8.9b or 0.8.9c

Sorry, patch v7 is mistake "Open at Startup" handling.
patch v7 has "Open at Startup" bug in multibyte language encoding name channel.


If you join #"multibyte language encoding name channel",
and set "Open at Startup" case,
and reboot chatzilla, so you can't join IRC server.
This is critical bug, Sorry.

Comment 16

[NAITOH Jun]

Attachment: patch v2 for ChatZilla 0.8.9b

some fix for multibyte language encoding name channel probrem.
under case bug fixed.

/who
/invite <nick> <multibyte channnel>
/kick <nick> <reason>
I think that this kick explanation is right.
I think that chatzilla's kick explanation is wrong.

and , this patch include "Open at Startup" in  multibyte language encoding name
channel patch.
(attachment 90409 [details] [diff] [review] )

thanks

Comment 17

[Robert Ginda]

checked in to trunk

Comment 18

[NAITOH Jun]

I try Trunk nightly chatzilla.
(Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020802)

I try to use (join) Japanese(ISO-2022-jp) channel name.
It is work fine ;)
Thanks!