Message8619

Hi, Jeff,
So glad you found the cause and the fix. What do you mean the output is
still failing?
Thanks,
Rose
On Mon, Jun 9, 2014 at 4:03 PM, Jeff Allen <report@bugs.jython.org> wrote:
>
> Jeff Allen added the comment:
>
> Got it. The parser uses a Java codec, so a literal string has already been
> decoded from the console by the Java x-mswin-936 codec. But a literal
> string should contain the bytes equivalent to it in the input encoding. So
> the parser has to be reverse itself, and is trying to do that with the
> (non-existent) Python codec. But using the Java codec is more respectable,
> and it fixes the hang on input.
>
> >dist\bin\jython -Dpython.console=
> Jython 2.7b3+ (default:6cee6fef06f0+, Jun 9 2014, 23:22:52)
> [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_51
> Type "help", "copyright", "credits" or "license" for more information.
> >>> "xx"
> 'xx'
> >>> "畫蛇添足"
> '\xae\x8b\xc9\xdf\xcc\xed\xd7\xe3'
> >>> u"畫蛇添足"
> u'\u756b\u86c7\u6dfb\u8db3'
> >>> exit()
>
> This doesn't work with the default JLineConsole as that seems to have no
> idea about multibyte characters.
>
> Output is still failing, as that really does need the codecs from #1066.
>
> I'll push this small change after tests, and then think how to avoid the
> non-Python name "x-mswin-936".
>
> On the wrapping issue, Jim: if someone defined a codec in Python, then
> used it a the source encoding, it would be necessary to be able to create a
> Java codec from it, since the parser has to use it as the decoding in a
> Reader. In the present design, that is.
>
> _______________________________________
> Jython tracker <report@bugs.jython.org>
> <http://bugs.jython.org/issue2123>
> _______________________________________
>