https://bugs.documentfoundation.org/show_bug.cgi?id=159936
Mike Kaganski <mikekagan...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |NOTABUG
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Mike Kaganski <mikekagan...@hotmail.com> ---
(In reply to Masaru Nakanishi from comment #2)
> Is this a problem specific to the Japanese environment?
The *B functions are invented (by Microsoft? Or maybe Lotus?) specifically for
CJK environments. However, the functions also work in other environments. But
yes, there is a difference in Japanese environment, that two specific
characters (REVERSE SOLIDUS U+005c "\" and EURO SIGN U+20ac "€") also
considered two-byte, unlike in all other environments.
Their purpose was (back then, in pre-Unicode era, when they were introduced) to
provide you the correct byte length of the string (because specific characters
took 2 bytes in the DBCS encodings). These functions would only be needed when
you need to count bytes, not characters (maybe when you intend to write stuff
to files?). And in Calc, where the internal encoding is UFT-16, it makes almost
no sense. However, the functions are there for interoperability.
But here you deal with *characters*, not bytes. Thus, just avoid functions that
try to work with "bytes". Indeed, as I mentioned in comment 1, using LENB/MIDB,
you will tell the program to use "halves of characters". Trying to add half of
any character to your string makes no sense. And the implementation [1] adds a
space instead of such a half-character, as you see.
So, according to your reply (using LEN+MID works fine, as expected; LENB+MIDB
and a mix produces expected unwanted result), I close it NOTABUG.
Thank you!
[1]
https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/interpr1.cxx?r=c7664873&mo=327585&fi=9794#9794
--
You are receiving this mail because:
You are the assignee for the bug.
