Eclipse Community Forums: EMF » The carriage-return (#xD) character saved as "\r"

Help

Home

Home » Modeling » EMF » The carriage-return (#xD) character saved as "\r"

Show: Today's Messages :: Show Polls :: Message Navigator

The carriage-return (#xD) character saved as "\r" [message #427929]

Fri, 06 March 2009 10:28

koloale

Messages: 41
Registered: July 2009

Member

Hello!

When I save resource using Default XML serialization and in that
resource some element with value e.g. "Hello\r\nWorld!" is contained, I
get XML like that: "Hello\r\n". I know that  is XML entity
representin Unicode character for CR, but why it's saved twice as xml
entity and as '\r' char? Can you clarify this point: how actually save
CR character correctly?

Thank you,
Alexey

Report message to a moderator

Re: The carriage-return (#xD) character saved as "\r" [message #427933 is a reply to message #427929]

Fri, 06 March 2009 10:58

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Hi,

Well the reason that \r is saved as an escape sequence is that when
reading XML-Spec it states that \r\n is normalized to \n when parsing
XML. So when reading back the file using an standard compilant
XML-Parser the resulting string is:

"Hello\r\n"

because \r\n is normalized to \n. Why the \r is kept when serializing is
something I can't tell you but at least it should make no difference to you.

Tom

koloale schrieb:
> Hello!
>
> When I save resource using Default XML serialization and in that
> resource some element with value e.g. "Hello\r\nWorld!" is contained, I
> get XML like that: "Hello\r\n". I know that  is XML entity
> representin Unicode character for CR, but why it's saved twice as xml
> entity and as '\r' char? Can you clarify this point: how actually save
> CR character correctly?
>
> Thank you,
> Alexey

Report message to a moderator

Re: The carriage-return (#xD) character saved as "\r" [message #427939 is a reply to message #427933]

Fri, 06 March 2009 11:59

Ed Merks

Messages: 33217
Registered: July 2009

Senior Member

Guys,

I think if you see \r or \n in the serialization it's because you have
the two characters \ followed r or n in the string itself. I can't
imagine that serialization would ever convert a character into a Java
escape sequence. Some other aspect of the logic (not the serialization
log) must be doing that...

Tom Schindl wrote:
> Hi,
>
> Well the reason that \r is saved as an escape sequence is that when
> reading XML-Spec it states that \r\n is normalized to \n when parsing
> XML. So when reading back the file using an standard compilant
> XML-Parser the resulting string is:
>
> "Hello\r\n"
>
> because \r\n is normalized to \n. Why the \r is kept when serializing is
> something I can't tell you but at least it should make no difference to you.
>
> Tom
>
> koloale schrieb:
>
>> Hello!
>>
>> When I save resource using Default XML serialization and in that
>> resource some element with value e.g. "Hello\r\nWorld!" is contained, I
>> get XML like that: "Hello\r\n". I know that  is XML entity
>> representin Unicode character for CR, but why it's saved twice as xml
>> entity and as '\r' char? Can you clarify this point: how actually save
>> CR character correctly?
>>
>> Thank you,
>> Alexey
>>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: The carriage-return (#xD) character saved as "\r" [message #427949 is a reply to message #427939]

Fri, 06 March 2009 13:23

koloale

Messages: 41
Registered: July 2009

Member

Ed Merks wrote:
> Guys,
>
> I think if you see \r or \n in the serialization it's because you have
> the two characters \ followed r or n in the string itself. I can't
> imagine that serialization would ever convert a character into a Java
> escape sequence. Some other aspect of the logic (not the serialization
> log) must be doing that...
Ed, what do mean by 'some other aspect of the logic must be doing that'?
My code is:

EObject config = EcoreUtil.create(someClass);
config .eSet(ref, "Hello\r\nWorld");

Resource resource = ;
resource .getContents().add(config);

ByteArrayOutputStream os = new ByteArrayOutputStream();
resource.save(os, null);
assertEquals("Hello\r\nWorld", os.toString());

So I think it is XMLResourceImpl that convert \r to 

Alexey

Report message to a moderator

Re: The carriage-return (#xD) character saved as "\r" [message #427951 is a reply to message #427949]

Fri, 06 March 2009 13:50

Ed Merks

Messages: 33217
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------010401000603070907050808
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Alexey,

Comments below.

koloale wrote:
> Ed Merks wrote:
>> Guys,
>>
>> I think if you see \r or \n in the serialization it's because you
>> have the two characters \ followed r or n in the string itself. I
>> can't imagine that serialization would ever convert a character into
>> a Java escape sequence. Some other aspect of the logic (not the
>> serialization log) must be doing that...
> Ed, what do mean by 'some other aspect of the logic must be doing that'?
> My code is:
>
> EObject config = EcoreUtil.create(someClass);
> config .eSet(ref, "Hello\r\nWorld");
>
> Resource resource = ;
> resource .getContents().add(config);
>
> ByteArrayOutputStream os = new ByteArrayOutputStream();
> resource.save(os, null);
> assertEquals("Hello\r\nWorld", os.toString());
>
> So I think it is XMLResourceImpl that convert \r to 
Well yes. Tom already mentioned that and why. If it didn't do that,
what you'd get back when reading it would be the value "Hello\nWorld"
because any XML parser will convert the system's line feed convention to
"\n". The serializer is written so it preserves *exactly *the sequence
of characters you specified. (I thought when you said \r\n you
literally meant those two letter escape sequence appeared in the XML file...
>
> Alexey

--------------010401000603070907050808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alexey, 
 
Comments below. 
 
koloale wrote:
<blockquote cite="mid:gor856$qmp$1@build.eclipse.org" type="cite">Ed
Merks wrote:
 
<blockquote type="cite">Guys,
 
 
I think if you see \r or \n in the serialization it's because you have
the two characters \ followed r or n in the string itself. I can't
imagine that serialization would ever convert a character into a Java
escape sequence. Some other aspect of the logic (not the serialization
log) must be doing that...
 
</blockquote>
Ed, what do mean by 'some other aspect of the logic must be doing
that'?
 
My code is:
 
 
EObject config = EcoreUtil.create(someClass);
 
config .eSet(ref, "Hello\r\nWorld");
 
 
Resource resource = ;
 
resource .getContents().add(config);
 
 
ByteArrayOutputStream os = new ByteArrayOutputStream();
 
resource.save(os, null);
 
assertEquals("Hello&#xD;\r\nWorld", os.toString());
 
 
So I think it is XMLResourceImpl that convert \r to &#xD;
 
</blockquote>
Well yes. Tom already mentioned that and why. If it didn't do that,
what you'd get back when reading it would be the value "Hello\nWorld"
because any XML parser will convert the system's line feed convention
to "\n". The serializer is written so it preserves exactly the
sequence of characters you specified. (I thought when you said \r\n
you literally meant those two letter escape sequence appeared in the
XML file... 
<blockquote cite="mid:gor856$qmp$1@build.eclipse.org" type="cite"> 
Alexey
 
</blockquote>
</body>
</html>

--------------010401000603070907050808--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: The carriage-return (#xD) character saved as "\r" [message #427960 is a reply to message #427933]

Fri, 06 March 2009 18:57

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

I imagine the reason the \r still shows up is because the save()
function will turn \n into the current platform's new line characters,
which on windows is \r\n.

So first it was turned into "\n" by the XML serialization and then
the function turned that last remaining \n into \r\n because that is the
current platform's new line characters.

--
Thanks,
Rich Kulp

Report message to a moderator

Previous Topic:	URI Encoding problem
Next Topic:	reflection

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Sep 24 01:22:01 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter