When transcoding from UTF8 to Latin1, we create a new node::Converter for "iso8859-1".
The call chain goes:
node::Converterucnv_openucnv_createConverterucnv_loadSharedDataucnv_io_getConverterName
This is where the version of ICU included in Node.js and the one in Chromium differs. The former returns nullptr, whereas the latter returns "windows-1252-html"
"windows-1252-html" is a superset of "iso8859-1" that includes the EURO sign, which is tested in this particular test:
const orig = Buffer.from('tést €', 'utf8');Since the EURO sign fits into "windows-1252-html", we do not need to resort to the substitution character ("?"). That's why the test fails.
The reason Node's ICU fails is this call chain:
ucnv_io_getConverterNamehaveAliasDatainitAliasDataudata_openChoice
Chromium's ICU returns a valid UDataMemory* object, but Node's ICU returns a nullptr.
I'm unsure whether this is a bug in Node.js.
When transcoding from UTF8 to Latin1, we create a new
node::Converterfor "iso8859-1".The call chain goes:
node::Converterucnv_openucnv_createConverterucnv_loadSharedDataucnv_io_getConverterNameThis is where the version of ICU included in Node.js and the one in Chromium differs. The former returns
nullptr, whereas the latter returns"windows-1252-html""windows-1252-html" is a superset of "iso8859-1" that includes the EURO sign, which is tested in this particular test:
Since the EURO sign fits into "windows-1252-html", we do not need to resort to the substitution character ("?"). That's why the test fails.
The reason Node's ICU fails is this call chain:
ucnv_io_getConverterNamehaveAliasDatainitAliasDataudata_openChoiceChromium's ICU returns a valid
UDataMemory*object, but Node's ICU returns anullptr.I'm unsure whether this is a bug in Node.js.