Menu

#2281 Error "Invalid UTF-8 sequence" and "Not enough space" when compiling ANSI files (WINDOWS)

open
nobody
2018-03-13
2018-03-12
Anonymous
No

Originally created by: xelloss1012

Issue

When trying to compile files that are encoding as ANSI (Windows-1252) and have some special characters (i.e. ñ, á, é, etc.), even if this characters are only in a comment, we are getting 2 types of error.

We use this code to compile the files:

sass.render({
        file: filename,
        outputStyle: "nested"            
    }, function (err, result) {
        console.log(err);        
    });

Then, when trying to compile a file with this exact contents:

//á
div {
}

We get this error:

{ Error: Invalid UTF-8 sequence
    at options.error (C:\gitrepos\build-tools\node_modules\node-sass\lib\index.js:291:26)
  status: 1,
  file: 'C:/gitrepos/build-tools/tests/node-sass/v4.8.1/ansi1.scss',
  line: 1,
  column: 3,
  message: 'Invalid UTF-8 sequence',
  formatted: 'Error: Invalid UTF-8 sequence\n        on line 1 of tests/node-sass/v4.8.1/ansi1.scss\n>> //�\r\ndiv {\r\n   --^\n' }

And when trying to compile a file with this other contents:

//aquí todas las reglas que sean necesarias para conseguir la mejor visualización
div {
}

We get a different error:

{ Error: Not enough space
    at options.error (C:\gitrepos\build-tools\node_modules\node-sass\lib\index.js:291:26)
  status: 3,
  message: 'Not enough space',
  formatted: 'Internal Error: Not enough space\n' }

I think both errors are the same, since sometimes changing a little the contents of the file it appears one error or the other.

I have attached the problematic files so you can reproduce the error in an easier way.

test ansi node-sass 4.8.1.zip

Is important to note that this error only happens when the file is encoded as ANSI (Windows-1252). When the file is encoded as UTF-8 it works perfectly. However, even if a file is encoded as UTF-8 (or as ANSI but without any special characters), the error also occurs if any of its import files meets this conditions.

Note that in node-sass 4.7.2 was working great (with libsass 3.5.0.beta.2) so it seems related to the latest release of node-sass 4.8.1 (with libsass 3.5.0).

System info

  • NPM version (npm -v): 5.6.0
  • Node version (node -v): v8.9.4
  • Node Process (node -p process.versions):
    { http_parser: '2.7.0',
    node: '8.9.4',
    v8: '6.1.534.50',
    uv: '1.15.0',
    zlib: '1.2.11',
    ares: '1.10.1-DEV',
    modules: '57',
    nghttp2: '1.25.0',
    openssl: '1.0.2n',
    icu: '59.1',
    unicode: '9.0',
    cldr: '31.0.1',
    tz: '2017b' }
  • Node Platform (node -p process.platform): win32
  • Node architecture (node -p process.arch): x64
  • node-sass version (node -p "require('node-sass').info"):
    node-sass 4.8.1 (Wrapper) [JavaScript]
    libsass 3.5.0 (Sass Compiler) [C/C++]
  • npm node-sass versions (npm ls node-sass): node-sass@4.8.1

Discussion

  • Anonymous

    Anonymous - 2018-03-12

    Originally posted by: xzyfer

    @xelloss1012 thanks for the report. Apologies for the regression. I've confirmed the issues you've mentioned on LibSass 3.5.0.

    I'm current debugging [#2280] which is relatively urgent. I'll don't expect to get to this before tomorrow.

    cc @mgreter you might know where to look off the top of your head.

     
  • Anonymous

    Anonymous - 2018-03-12

    Originally posted by: mgreter

    This is intended behavior to avoid invalid parsing results (as reported multiple times) and unexpected segfaults when printing error messages etc. We currently only support utf8 (and therefore plain ascii). Supporting single byte encodings should be possible though (detecting charset and replace everything utf8 related with single byte logic) ...

    https://www.w3.org/International/questions/qa-choosing-encodings

     
  • Anonymous

    Anonymous - 2018-03-12

    Originally posted by: xzyfer

    @xelloss1012 apologies I didn't notice the breaking change. As a work around for now you'll need to lock to node-sass@~4.7.

     
  • Anonymous

    Anonymous - 2018-03-12

    Originally posted by: xelloss1012

    Ok, for me there is no problem, we have version locked to 4.7 to avoid this issue and I think we can live with this by the moment :)

    But I suspect this issue can be affecting a number of users, since ANSI is the default encoding used in Windows and in some Windows developer tools like Visual Studio... In special to non english users that may be writing comments with special characters, etc.

    Thank you very much for your comments!

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.