Bug 9257 - ELParser doesn't parse non-ascii value
Summary: ELParser doesn't parse non-ascii value
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2002-05-20 21:31 UTC by Kan Ogawa
Modified: 2010-01-03 00:24 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Kan Ogawa 2002-05-20 21:31:56 UTC
I tried to set default value with <c:out> action.

  <c:out value="${customer.phoneHome}" default="XXXX">
  notice: XXXX is a value contains multibyte characters.

When I open web location, an error occurred.
The error message is displayed as follows.
  ??????? c ??????????????????
  null: tag = 'out' / attribute = 'default':
  An error occurred while parsing custom action attribute "default" with
value "??":
  Lexical error at line 1, column 1. Encountered: "\u306a" (12394),
after : ""

I just noticed that the ELParser.jj has UNICODE_INPUT set to
false (by default).  The fix should be as simple as setting it to true and
regenerating the parser.
Comment 1 Prasad Subramanian 2002-05-21 17:56:34 UTC
Would it be possible for you to list the JSP code in which this is happening
Comment 2 Prasad Subramanian 2002-05-21 18:10:59 UTC
I was able to reproduce this :
Comment 3 Nathan Abramson 2002-05-21 18:27:37 UTC
Bug 9257 - ELParser doesn't parse non-ascii value

As Kan suggested, I've added UNICODE_INPUT = true to the ELParser.jj
options.  This doesn't seem to have caused any regression in the
existing command line parser tests.

I also added a new command line parser test to try inputting a
non-ascii string.  I've confirmed that without the fix, the string
causes an error, whereas with the fix, the string is processed

So, this appears to be fixed.  However, I don't have easy access to
non-ascii pages so I haven't completely confirmed this fix in an
actual JSP.  I would appreciate it if someone would confirm this fix
Comment 4 Kan Ogawa 2002-05-21 20:10:00 UTC
I tried to do the existing command-line parser tests with the regenerated 
so I have appreciated correctly.
In this case, the tested non-ascii string is not "\u1111" but "\u30c6\u30b9
( "\u1111" code isn't displayed fundamentally under Japanese environment. )

And I also have completely confirmed this fix in an actual JSP.

Kan Ogawa
Comment 5 Nathan Abramson 2002-05-21 20:13:38 UTC
Many Thanks!