Skip to content

TextDecoder('utf-8') doesn’t match spec #16894

Description

@srl295
  • Version: tested v8.5.0 / master
  • Subsystem: core

from discussion in #16876

in Node.js,

new (require('util').TextDecoder)('utf-8')
 .decode(Buffer.from([0xF0, 0x80, 0x80])).length === 1 // U+FFFD

But in Safari/FF/Chrome,

new TextDecoder('utf-8')
 .decode(new Uint8Array([0xF0, 0x80, 0x80])).length === 3 // U+FFFD U+FFFD U+FFFD

think Node.js is wrong here per https://encoding.spec.whatwg.org/#utf-8-decoder

//cc @mathiasbynens

Activity

  1. added
    i18n-apiIssues and PRs related to Node.js internationalization support.
    on Nov 9, 2017
  2. srl295 commented on Nov 9, 2017

    @srl295
    MemberAuthor
  3. jungshik commented on Nov 9, 2017

    @jungshik

    The code snippet above in web browsers(implementing TextDecoder API) should read as following:

    new TextDecoder('utf-8')
     .decode(new Uint8Array([0xF0, 0x80, 0x80])).length
    
  4. srl295 commented on Nov 9, 2017

    @srl295
    MemberAuthor

    @jungshik oops… exactly right. I fixed it.

  5. srl295 commented on Nov 9, 2017

    @srl295
    MemberAuthor

    ^ already fixed in v8 (see link above)

    Yea I recently fixed this in V8. The fix is in V8 6.3.
    The relevant CL is https://chromium-review.googlesource.com/671020
    See also https://bugs.chromium.org/p/chromium/issues/detail?id=765608

  6. added
    v8 engineIssues and PRs related to the V8 dependency.
    on Nov 9, 2017
  7. tniessen commented on Nov 10, 2017

    @tniessen
    Member

    The relevant commit is v8/v8@6389b7e. Should we cherry-pick this for node 8?

  8. srl295 commented on Nov 10, 2017

    @srl295
    MemberAuthor

    @tniessen seems like a good idea—means the other UTF-8 handling (v8 internal, and via ICU) will be in line with TextDecoder

  9. TimothyGu commented on Nov 10, 2017

    @TimothyGu
    Member

    This issue really has nothing to do with V8, since TextDecoder is backed by ICU. On master, this has been fixed by #16876, but not in v9.x or earlier. It seems the original issue (TextDecoder) only affects released versions of Node.js. We'll also have to make the same fix for require('string_decoder').StringDecoder, if we were to go all in.

  10. added
    c++Issues and PRs that require attention from people who are familiar with C++.
    and removed
    v8 engineIssues and PRs related to the V8 dependency.
    on Nov 10, 2017
  11. TimothyGu commented on Nov 10, 2017

    @TimothyGu
    Member

    I guess we just need to backport

    to v8.x, where the TextDecoder API is actually stable; or we can just upgrade ICU to 60 in v8.x LTS. We'll also need tests, as it seems WPT does not currently contain any tests for this behavior. /cc @jasnell

  12. srl295 commented on Nov 11, 2017

    @srl295
    MemberAuthor

    No please do not backport those commits. V8 and not icu is used for utf -8. Check the code. @jasnell

  13. TimothyGu commented on Nov 11, 2017

    @TimothyGu
    Member

    @srl295 I have just backported the commits in my local branch, and this issue was fixed. Can you explain how V8 is used for UTF-8? If you mean

    return encodeUtf8String(`${input}`);
    , that is for TextEncoder, not TextDecoder.

  14. srl295 commented on Nov 11, 2017

    @srl295
    MemberAuthor
  15. TimothyGu commented on Nov 11, 2017

    @TimothyGu
    Member

    @srl295

    The issue I saw is there even with no icu

    no-icu uses string_decoder.StringDecoder, which as I noted in #16894 (comment) handles this wrongly as well.

  16. srl295 commented on Nov 16, 2017

    @srl295
    MemberAuthor
  17. jasnell commented on Aug 11, 2018

    @jasnell
    Member

    appears to be fixed in 10.x and master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    c++Issues and PRs that require attention from people who are familiar with C++.i18n-apiIssues and PRs related to Node.js internationalization support.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions