`TextEncoder.encodeInto()` underfills the destination for some non-ASCII text
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 84/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- cpp, javascript, nodejs
Hướng nghiên cứu
Bắt đầu trong src/encoding_binding.cc, đặc biệt là simpleUtfEncodingLength() và findBestFit(), sau đó kiểm tra phạm vi bao phủ WPT trong encodeInto.any.js. Tái hiện các ví dụ gồm 33 ký tự và bổ sung phạm vi bao phủ cho U+0400–U+07FF cùng các đích hẹp; hoàn tất khi encodeInto báo cáo các giá trị đọc/ghi mong đợi và các bài kiểm thử WPT liên quan đều đạt.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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]));
- Ngôn ngữ chính
- JavaScript
- Star
- 122k
- Fork
- 37.4k
- Merge trung bình
- 4 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 273
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của nodejs/node
-
doc
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
-
build
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
-
feature request
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
stale
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
HarperFast/skills#96 ·
-
[Block] Latest Posts [Type] Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
Daemon passes --experimental-wasm-jspi unconditionally on Node >= 24; Node 26 rejects the flag Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Automattic/studio#4908 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
sugarlabs/musicblocks#8847 ·