Changes between Initial Version and Version 1 of Ticket #15969, comment 7


Ignore:
Timestamp:
Sep 24, 2012, 10:23:24 PM (7 years ago)
Author:
Douglas Hays
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #15969, comment 7

    initial v1  
    1 Shrinksafe (via Java) is transcoding the string text \uFFFF (6 ASCII bytes) to the shorter UTF-8 characters EF BF BF (3 bytes).  But \uFFFE and \uFFFF and reserved by the Unicode as for private use and are listed as non-characters and should not be transcoded.  Refer to [http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Private_use_characters].  This is somewhat the same as #5027 in which the null character was forced to be escaped within Shrinksafe. rcgill's JS workaround is sufficient but I would recommend fixing Shrinksafe by adding similar exceptions for 0xFFFE and 0xFFFF as well.  Since we're dropping Shrinksafe and it's not a problem in the closureCompiler,, I'd hate to munge the JS code that will remain beyond Shrinksafe.
     1Shrinksafe (via Java) is transcoding the string text \uFFFF (6 ASCII bytes) to the shorter UTF-8 characters EF BF BF (3 bytes).  But \uFFFE and \uFFFF are reserved by the Unicode spec for private application use and are listed as non-characters and should not be transcoded.  Refer to [http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Private_use_characters].  This is somewhat the same as #5027 in which the null character was forced to be escaped within Shrinksafe. rcgill's JS workaround is sufficient but I would recommend fixing Shrinksafe by adding similar exceptions for 0xFFFE and 0xFFFF as well.  Since we're dropping Shrinksafe and it's not a problem in the closureCompiler, I'd hate to munge the JS code that will remain beyond Shrinksafe.