Description
- Version:
v10.16.2
(using nvm I can reproduce withv12.9.0
too) - Platform:
Linux stormo 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC 2019 x86_64 GNU/Linux
- Subsystem: console
I've been comparing differences between currency formattings for different locales, when I stumbled across a minor irregularity in the output of console.table
.
Consider the following example code:
const items = [
{foo: '2', bar: '3'},
{foo: '¥2', bar: '3'},
{foo: '2', bar: 'abcdefghijklmnopqrstuvwxyz'},
{foo: '-¥12,345,678.90', bar: '¥-12,345,678.90'},
{foo: '¥2', bar: '¥3'},
{foo: '2', bar: '3'},
];
console.table(items);
The resulting console output on my machine appears like this:
From what I can gather so far:
- It seems that simply having
¥
in a string is sufficient to provoke the behavior given that it is theFULLWIDTH YEN SIGN
(U+FFE5) and not theYEN SIGN
(U+00A5). - The behavior seems to be independent of table length - >400 items as well as a single item had the formatting oddity.
- It seems that having a longer string like
abc…xyz
in a different row doesn't change the outcome.
To me this hints that the length for the specific strings with ¥
in it could be calculated to be shorter than it actually is.
For completeness here's a screenshot of the original output I encountered:
After realizing that there are also rather short entries in my original output, I've created this additional test case:
const items = [
{foo: '¥', bar: '¥'},
];
console.table(items);
const [{ foo, bar }] = items;
console.log({foo});
console.table(Array.from(foo + bar).map((s) => ({s, charCode: s.charCodeAt(0), length: s.length})));
The corresponding output looks like this:
It appears that the problem here lies with charCode 65509
rather than with 165
.
So I'm concerned about the FULLWIDTH YEN SIGN at code point U+FFE5
rather than the YEN SIGN at code point U+00A5
.
I've had a look at #27915 before and am under the impression that this is the right channel for this kind of issue. Please feel free to educate me otherwise ;)