hungdluit / flowlib

Automatically exported from code.google.com/p/flowlib
0 stars 0 forks source link

Russian symbols are displayed in the incorrect encoding #15

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Join any russian hub
2. Watch nicklist 

What is the expected output? What do you see instead?
- please watch attached image

What version of the product are you using? ~~(Do not write latest)~~
FlowLib 2008/Nov/21 (SVN)

On what operating system?
Windows XP sp2

Call Stack? ~~(Line numbers and exception type helps much)~~
No exceptions.

Please provide any additional information below.
-All works fine in FlowLib third release

Original issue reported on code.google.com by hackw...@gmail.com on 21 Nov 2008 at 8:36

Attachments:

GoogleCodeExporter commented 8 years ago
I can see such wrong symbols in browser when I select codepage 1252 instead of 
1251.
I have made attempt to convert new library output from all codepages exist in 
system 
but has no result.

Original comment by hackw...@gmail.com on 21 Nov 2008 at 8:47

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
After comparing sources I found a reason of issue. This issue happens because 
encoding 1252 selected instead of system default. Source location: Protocols
\hubnmdcprotocol.cs, line 75. 

        public System.Text.Encoding Encoding
        {
            //get { return System.Text.Encoding.Default; }
            get
                        {
                                try {
                                        return System.Text.Encoding.GetEncoding
(1252);
                                } catch (System.Exception e) {
                                        System.Console.WriteLine(e.ToString());
                                        throw;
                                }

                        }
                        // 
        } 
can you fix it in svn?

Original comment by hackw...@gmail.com on 22 Nov 2008 at 12:19

GoogleCodeExporter commented 8 years ago
Switching back to system default doesn't solve the problem.
Yes, it makes YOU see Russian chars BUT others may not. All depends on what 
language
they have set as default on their system. Me for example will not see Russian 
chars.

The reason why i changed from default to 1252 was that the lock and key 
algorithm
used in NMDC protocol expects 1252 encoding. When encoding is not set to 1252 
the
algorithm doesn't always work, making it impossible to connect to hub.

If all hubs where using ADC protocol this wouldn't be a problem as ADC uses 
UTF-8
encoding.

I don't know a good solution to this. As it is now you will at least always be 
able
to connect to hub.

If you come up with an idea, I'm happy to hear it.

Original comment by blomman84 on 23 Nov 2008 at 10:50

GoogleCodeExporter commented 8 years ago
Then maybe use 1252 encoding only for establish connection with hub?

Original comment by hackw...@gmail.com on 23 Nov 2008 at 3:28

GoogleCodeExporter commented 8 years ago
If i make it possible to set the Encoding property to something else. Would 
that be a
good solution for your?

Original comment by blomman84 on 25 Nov 2008 at 10:41

GoogleCodeExporter commented 8 years ago
I think yes. Can you say me when I need to change encoding to avoid key check 
problem?

Original comment by hackw...@gmail.com on 25 Nov 2008 at 12:41

GoogleCodeExporter commented 8 years ago
You can probably change it when RegModeUpdated event has been trigged.
As RegModeUpdated is a static event you need to use the sender param from the 
event
to get the hub object (This is so you don't change Encoding for all hubs you 
have open).

If (hub.RegMode >= 0) {
   // We are past the key & lock exchange.
   SetYourEncoding();
}
else
{
   // We have been disconnected and should be prepared for key & lock exchange.
   SetEncodingUsedFromBegining();
}

I will post a message in here when i have committed a change in SVN.

Original comment by blomman84 on 25 Nov 2008 at 1:00

GoogleCodeExporter commented 8 years ago
A fix has been committed.
Can you test it and come back to me?
Can you test file transfers too?

Original comment by blomman84 on 25 Nov 2008 at 1:16

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Sure. I will test it and post results here. Thank you very much.

Original comment by hackw...@gmail.com on 25 Nov 2008 at 3:15

GoogleCodeExporter commented 8 years ago
Everything works fine. Thanks a lot.

Original comment by hackw...@gmail.com on 5 Feb 2009 at 2:51

GoogleCodeExporter commented 8 years ago
Good. Issue closed :)

Original comment by blomman84 on 5 Feb 2009 at 6:39