Project

General

Profile

Bug #640

iso-2022-jp encoding not honored anywhere at all.

Added by salyavin over 12 years ago. Updated about 7 years ago.

Status:
Feedback
Priority:
Immediate
Assignee:
-
Category:
Quassel Core
Target version:
Start date:
03/21/2009
Due date:
% Done:

0%

Estimated time:
Version:
0.9-pre
OS:
Any

Description

Trying out this program but I find it does not honor custom encoding. When setting up a network for example irc2.2ch.net I set custom encodings and set all three to ISO-2022-JP. When I enter the channels I see garbage characters. If I try /charset ISO-2022-JP that does not work either. This is 0.4.0. I have also tried this on other networks like say rizon then joining #japanese which is an ISO-2022-JP channel. Remember in networks I am setting custom encoding and setting all three to ISO-2022-JP. Of course konversation, xchat etc. work correctly. If I join a utf-8 Japanese channel quassel does display Japanese characters correctly but without iso-2022-jp the program is unusable for me. I am operating KDE 4.2 on 64 bit Gentoo Linux. This also applies in show channel list etc. like on irc2.2ch.net when all 3 custom encoding are set to iso-2022-jp many channel names are garbage characters (the channel names are encoded in iso-2022-jp and are Japanese characters).

History

#1 Updated by salyavin over 12 years ago

I tried this with the gentoo ebuild (compile from source) x64 precompiled nightly binary listed on this site and gentoo ebuild from repository (did a checkout of source and compiled). I also tried connecting with a windows client on a work machine to the linux core server.

#2 Updated by EgS over 12 years ago

Could you please tell us where we can test this?
You said someting about a channel called #japanese, but on which network?

#3 Updated by EgS over 12 years ago

Thanks to some mild poking in the eye from seezer, I managed to figure the network out ;)

#4 Updated by EgS over 12 years ago

  • Category changed from Quassel GUI (KDE) to Quassel Core
  • Status changed from New to Assigned
  • Assignee set to Sputnick

Reproduced the issue.

Assigning to Sput, as it seems to be an issue with the UTF-8 autodetection.
Perhaps we should disable the UTF-8 detection in some cases.

#5 Updated by salyavin over 12 years ago

Thank you for looking at this. I am sure dealing with UTF-8 autodetection must be difficult.

BTW there are some iso-2022-jp channels on freenode like #wikipedia-ja-articles #wikinews-ja #wikipedia-ja-vandalism yet others are UTF-8 like #gentoo-ja or #nihongo irc2.2ch.net is a good test I think as it is a Japanese IRC server with some channel names, MOTD etc. in iso-2022-jp and I think all channels on that network are encoded iso-2022-jp. If it is down it is joined with irc.juggler.jp

Yes irc.rizon.net #japanese is in iso-2022-jp and has a decent amount of activity. It is joined with #japanese on irc2.2ch.net but sometimes too much English I think.

#6 Updated by salyavin over 12 years ago

Just wanted to say I consider disabling UTF-8 autodetection as EgS suggests seems the easiest solution.

#7 Updated by Xzaws almost 11 years ago

Quassel 0.7.1; same problems. =/
Gentoo x64. whines

#9 Updated by khris almost 10 years ago

I agree with salyavin's opinion. It's a simple and easy solution that disabling UTF-8 auto-detection as an feature.

Guessing encoding is a over enginieering for UTF-8 auto detection bugs. And multibyte encoding is not only japanese codecs but also korean's and chinese's too.

#10 Updated by rikai over 9 years ago

Just confirming that this still exists in 0.8.0...

This really is a pretty big bug. It makes chatting in any channel using iso-2022-jp absolutely impossible.

Perhaps the priority of this bug should be bumped up, since it breaks the core function of quassel, chatting?

#11 Updated by Anonymous over 8 years ago

  • Assignee deleted (Sputnick)
  • Priority changed from Normal to Immediate
  • Version changed from 0.4.0 to 0.9-pre
  • OS changed from Linux to Any

#12 Updated by Anonymous over 8 years ago

  • Assignee set to Anonymous
  • Target version set to Some future release

Fixed'ish in PR 7 ; I added a blacklist of codecs which should bypass the detection. Testing showed that EUC-{JP,KR} and Shift-JIS worked fine, so I only added ISO-2022-JP to the blacklist. If others are wrongly detected, please nudge me.

#13 Updated by Anonymous over 8 years ago

  • Status changed from Assigned to Resolved
  • Target version changed from Some future release to 0.9.0

#14 Updated by Orbixx about 7 years ago

  • Status changed from Resolved to Feedback
  • Target version changed from 0.9.0 to Some future release

This is still not resolved as of 0.10.0 on both client and core. Attempting to set is-2022-jp via the network configuration UI results in it syncing with the core and then displaying default values again, disregarding the set values. Some other unusual behaviour is also exhibited with other random encoding selections, but not all of them.

Can anybody replicate this?

Also available in: Atom PDF