Because the '\n' character is used as a field delimiter, the spec defines the two-character string "\n" as an embedded newline within a field value. Without further escaping rules, this makes it impossible to intentionally use those characters together.
For example, a field may have a Windows filesystem path as value, C:\bat_calls\new\, but a newline would inadvertently be inserted between C:\bat_calls and new\.
Should we then define the two-character string "\\" to represent the character '\'? The above example would then need to be encoded as C:\\bat_calls\\new\\.
It should also be decided if these special escape characters apply to all string values, or exclusively to fields which specify "multi-line string" values?
For what it's worth, escaping a single token like "\n" is simple; simultaneously escaping several tokens, especially tokens containing the '\' character (which itself escapes special characters in C-based languages), is non-trivial.
Because the '\n' character is used as a field delimiter, the spec defines the two-character string "\n" as an embedded newline within a field value. Without further escaping rules, this makes it impossible to intentionally use those characters together.
For example, a field may have a Windows filesystem path as value,
C:\bat_calls\new\, but a newline would inadvertently be inserted betweenC:\bat_callsandnew\.Should we then define the two-character string "\\" to represent the character '\'? The above example would then need to be encoded as
C:\\bat_calls\\new\\.It should also be decided if these special escape characters apply to all string values, or exclusively to fields which specify "multi-line string" values?
For what it's worth, escaping a single token like "\n" is simple; simultaneously escaping several tokens, especially tokens containing the '\' character (which itself escapes special characters in C-based languages), is non-trivial.