OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Achieving interoperability in a world where different OS'srepresent newline differently

Hi Folks,

Each operating system has its own convention for signifying the end of a line of text:

Unix: the newline is a character, with the value hex A (LF).

MS Windows: the newline is a combination of two characters, with the values hex D (CR) and hex A (LF), in that order.

Mac OS: the newline is a character, with the value hex D (CR).

This operating-system-dependency of newlines can cause interoperability problems: the newlines in a string created on a Unix box will not be understood by applications running on a Windows box.

Here is how the newline problem is resolved in XML and in JSON:

XML: all newlines are normalized by an XML parser to hex A (LF). So it doesn't matter whether you create your XML document on a Unix box, a Windows box, or a Macintosh box, all newlines will be represented as hex A (LF).

JSON: multi-line strings are not permitted! So the newline problem is avoided completely. You can, however, embed within your JSON strings the \n (LF) or \r\n (CRLF) symbols, to instruct processing applications: "Hey, I would like a newline here."

That is quite an interesting difference in approach between XML and JSON for dealing with the newline problem!

Please let me know of any errors or confusion in the above explanation. Thanks!


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS