Issue Details (XML | Word | Printable)

Key: AXIS-2342
Type: Bug Bug
Status: Open Open
Assignee: Axis Developers Mailing List
Reporter: Thiago Jung Bauermann
Votes: 5
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
Axis

Reopen issue: Character entities are escaped too aggressively

Created: 16/Dec/05 01:41 AM   Updated: 22/Feb/08 09:23 AM
Component/s: Serialization/Deserialization
Affects Version/s: 1.0
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments:
  Size
File Licensed for inclusion in ASF works AXIS_2342.diff 2007-04-23 03:10 PM Rodrigo Ruiz 3 kB
Text File Licensed for inclusion in ASF works PATCH_2342.txt 2006-01-27 07:39 AM Christian Müller 2 kB
File Licensed for inclusion in ASF works TEST_2342.diff 2007-04-24 08:40 AM Rodrigo Ruiz 5 kB
Text File Licensed for inclusion in ASF works TESTCASE_2342.txt 2006-01-27 07:39 AM Christian Müller 3 kB
Environment:
Operating System: All
Platform: All
Issue Links:
Cloners
 

Bugzilla Id: 19327


 Description  « Hide
We are using SOAP to send XML documents from client to server and back. The
documents contain a lot of non-ASCII data. This is encoded as UTF-8 by us.
However, when retrieved from an Axis server, Axis will escape almost all of our
characters into character entities (so &#...;) This means messages become about
three times as big as they have to for 'international' documents, which for us
is a large performance problem. I narrowed down the problem to
  XMLUtils::xmlEncodeString
that has the code:
                if (((int)chars[i]) > 127) {
                        strBuf.append("&#");
                        strBuf.append((int)chars[i]);
                        strBuf.append(";");
This seems unnecessary to me, as Axis will send all messages in UTF-8 anyway,
for which no encoding is necessary (and should encoding be configurable, I feel
this should be escaped elsewhere).

Is there any reason for this code, I commented it out and it seemed to have no
adverse effect on our application (apart from reduced network traffic)?

Tested with 1.0, also looked up in the sources of 1.1-rc2.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
No work has yet been logged on this issue.