`TextEncoder.encodeInto()` underfills the destination for some non-ASCII text
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- cpp, javascript, nodejs
Research direction
Start in src/encoding_binding.cc, especially simpleUtfEncodingLength() and findBestFit(), then inspect the encodeInto.any.js WPT coverage. Reproduce the 33-character examples and add coverage for U+0400–U+07FF and narrow destinations; done means encodeInto reports the expected read/written values and the relevant WPT tests pass.
Written by the indexing model from the issue text.
Description
There are two problems I found with TextEncoder.encodeInto(), both of which can cause encoding to stall even when the next char can fit the destination.
-
A 2-byte char requires a 3-byte destination
const encoder = new TextEncoder(); const text = '\u0400'.repeat(33); console.log(encoder.encodeInto(text, new Uint8Array(2))); // { read: 0, written: 0 } console.log(encoder.encodeInto(text, new Uint8Array(3))); // { read: 1, written: 2 }The second call proves that '\u0400' should fit into a 2-byte array.
-
Appending an unread character changes encoding progress
const encoder = new TextEncoder(); const text = 'é'.repeat(33); console.log(encoder.encodeInto(text, new Uint8Array(2))); // { read: 0, written: 0 } console.log(encoder.encodeInto(text + '☺', new Uint8Array(2))); // { read: 1, written: 2 }Appending
☺should not change whether preceding chars can be read into the buffer, but there it is.
The bugs were introduced by the encodeInto() performance change in Node.js v25.4.0. The examples above use length 33 strings to exercise that optimized path(kSmallStringThreshold = 32). Unfortunately the current encodeInto.any.js WPT tests fail to expose the problems because:
- all input cases use 7 or fewer code units
- even then, the cases don't use chars between U+0400 and U+07FF, and
- their cases don't contain a narrow dst capacity to reveal the signed-byte problem.
Proposed fixes
-
Incorrect cutoff in
simpleUtfEncodingLength()- if (c < 0x400) return 2; + if (c < 0x800) return 2;(very likely a typo, given the comment immediately below it says "Code points < 0x800: 2 bytes")
-
Signed-byte handling in
findBestFit()- size_t extra = simpleUtfEncodingLength(data[pos]); + size_t extra = simpleUtfEncodingLength(UTF16 ? data[pos] : static_cast<uint8_t>(data[pos]));
- Dominant language
- JavaScript
- Stars
- 122k
- Forks
- 37.4k
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 273
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nodejs/node
-
doc
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
build
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
feature request
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
stale
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
sugarlabs/musicblocks#8847 ·
-
client-controller-update ta-bot-triage team-money-movement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
MetaMask/metamask-mobile#36594 ·