Do not exclude Unicode noncharacters from rtl_convertUnicodeToText

For one, that broke round-tripping with e.g. UTF-8 (see the test case added to
Test::testComplex in sal/qa/rtl/textenc/rtl_textcvt.cxx) which did not treat
noncharacters as invalid.

For another, <https://unicode.org/faq/private_use.html#nonchar7> is meanwhile
quite clear on the matter:

"Q: Are noncharacters prohibited in interchange?

"A: This question has led to some controversy, because the Unicode Standard has
been somewhat ambiguous about the status of noncharacters. The formal wording of
the definition of 'noncharacter' in the standard has always indicated that
noncharacters 'should never be interchanged.' That led some people to assume
that the definition actually meant 'shall not be interchanged' and that
therefore the presence of a noncharacter in any Unicode string immediately
rendered that string malformed according to the standard. But the intended use
of noncharacters requires the ability to exchange them in a limited context, at
least across APIs and even through data files and other means of 'interchange',
so that they can be processed as intended. The choice of the word 'should' in
the original definition was deliberate, and indicated that one should not try to
interchange noncharacters precisely because their interpretation is strictly
internal to whatever implementation uses them, so they have no publicly
interchangeable semantics. But other informative wording in the text of the core
specification and in the character names list was differently and more strongly
worded, leading to contradictory interpretations.

"Given this ambiguity of intent, in 2013 the UTC issued Corrigendum #9, which
deleted the phrase 'and that should never be interchanged' from the definition
of noncharacters, to make it clear that prohibition from interchange is not part
of the formal definition of noncharacters. Corrigendum #9 has been incorporated
into the core specification for Unicode 7.0.

"Q: Are noncharacters invalid in Unicode strings and UTFs?

"A: Absolutely not. Noncharacters do not cause a Unicode string to be ill-formed
in any UTF. This can be seen explicitly in the table above, where every
noncharacter code point has a well-formed representation in UTF-32, in UTF-16,
and in UTF-8. An implementation which converts noncharacter code points between
one UTF representation and another must preserve these values correctly. The
fact that they are called 'noncharacters' and are not intended for open
interchange does not mean that they are somehow illegal or invalid code points
which make strings containing them invalid."

Change-Id: I4fcc0156e3d2fd305a7c7bb0c7b3dbef846c9e64
Reviewed-on: https://gerrit.libreoffice.org/78598
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

1 files changed, 9 insertions, 5 deletions

diff --git a/sal/textenc/convertiso2022cn.cxx b/sal/textenc/convertiso2022cn.cxx
index 76aee21f04b4..9e89c27486db 100644
--- a/sal/textenc/convertiso2022cn.cxx
+++ b/sal/textenc/convertiso2022cn.cxx
@@ -19,6 +19,9 @@
 
 #include <sal/config.h>
 
+#include <cassert>
+
+#include <rtl/character.hxx>
 #include <rtl/textcvt.h>
 #include <sal/types.h>
 
@@ -558,6 +561,11 @@ sal_Size ImplConvertUnicodeToIso2022Cn(void const * pData,
                 nHighSurrogate = static_cast<sal_Unicode>(nChar);
                 continue;
             }
+            else if (ImplIsLowSurrogate(nChar))
+            {
+                bUndefined = false;
+                goto bad_input;
+            }
         }
         else if (ImplIsLowSurrogate(nChar))
             nChar = ImplCombineSurrogates(nHighSurrogate, nChar);
@@ -567,11 +575,7 @@ sal_Size ImplConvertUnicodeToIso2022Cn(void const * pData,
             goto bad_input;
         }
 
-        if (ImplIsLowSurrogate(nChar) || ImplIsNoncharacter(nChar))
-        {
-            bUndefined = false;
-            goto bad_input;
-        }
+        assert(rtl::isUnicodeScalarValue(nChar));
 
         if (nChar == 0x0A || nChar == 0x0D) // LF, CR
         {