Move ByteString::FromUnicode() to WideString::ToDefANSI()

Turns out that "FromUnicode" is misleading in that, on linux, it simply
removes any characters beyond 0xFF and passes the rest unchanged, so
no unicode decoding actually takes place. On Windows, it passes it into
the system function specifying FX_CODEPAGE_DefANSI, converting it into
the so-called "default ANSI code plane", passing some characters,
converting others to '?' and still others to 'A'. Either way, nothing
resembling UTF8 comes out of this, so pick a better name.

These now immediately look suspicious, so a follow-up CL will see
which ones should really be WideString::UTF8Encode() instead.

Making this a normal method on a widestring rather than a static
method on a bytestring feels more natural; this is parallel to
the UTF8Encode and UTF16LE_Encode functions.

Add a test that shows these conversions.

Change-Id: Ia7551b47199eba61b5c328a97bfe9176ac8e583c
Reviewed-on: https://pdfium-review.googlesource.com/39690
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>

1 files changed, 2 insertions, 2 deletions

diff --git a/fpdfsdk/cpdfsdk_interform.cpp b/fpdfsdk/cpdfsdk_interform.cpp
index 3cfc84dfd9..6a4b591ed0 100644
--- a/fpdfsdk/cpdfsdk_interform.cpp
+++ b/fpdfsdk/cpdfsdk_interform.cpp
@@ -506,10 +506,10 @@ bool CPDFSDK_InterForm::FDFToURLEncodedData(uint8_t*& pBuf, size_t& nBufSize) {
       continue;
     WideString name;
     name = pField->GetUnicodeTextFor("T");
-    ByteString name_b = ByteString::FromUnicode(name);
+    ByteString name_b = name.ToDefANSI();
     ByteString csBValue = pField->GetStringFor("V");
     WideString csWValue = PDF_DecodeText(csBValue);
-    ByteString csValue_b = ByteString::FromUnicode(csWValue);
+    ByteString csValue_b = csWValue.ToDefANSI();
     fdfEncodedData << name_b << "=" << csValue_b;
     if (i != pFields->GetCount() - 1)
       fdfEncodedData << "&";