CKPackager: special characters are incorrectly(?) parsed by scriptcompressor

[Wiktor Walc]

If I'm correct, the following code in scriptcompressor.js:

value = value.replace( /[\b\t\n\v\f\r\\]/g, function( match )
{
	var chars =
	{
		'\b' : '\\b',
		'\t' : '\\t',
		'\n' : '\\n',
		'\v' : '\\v',
		'\f' : '\\f',
		'\r' : '\\r',
		'\\' : '\\\\'
	};

	return chars[ match ];
} );

translates back some special ASCII characters (this way if '\r\n' was in the source code, the compiled version of script also will contain exactly the same string: '\r\n').

However, the code above does not recognize the following characters which appear in CKEditor source code:

\ufeff
\u0085
\u00a0
\u1680
\u280e
\u2028
\u2029
\u202f
\u205f
\u3000
\x1b
\xa0

Is it done intentionally or is it a bug? I suspect it may cause some strange problems sooner or later.

[Frederico Caldeira Knabben]

That's not intentional, but a know issue. We'll never be able to have all escape sequences in that table.

The fact is that the Rhino parser transforms the string escape sequences into their real chars. In the case of \r\n this is a big problem, as it breaks the code:

BEFORE:
"Sample\r\nText"

AFTER:
"Sample
Text"

So we have to have the \r\n sequence included back. I've only included other escape sequences there because those are the standard ECMA sequences, not because they are really needed.

For other escape sequences, this is not a big issue, as long as the file gets saved as UTF-8. The "pure" character will just be there into the string, which is ok.

Please correct me if I'm wrong, reopening this ticket.

If for any reason we want to have only ASCII chars into the output files, then we should implement a different solution, which would seek for any non ASCII char and replace it with the proper escape sequence. But, we should avoid it in our case, as it would definitely produce big and unmanageable language files.