vcl/unx/gtk/fpicker/SalGtkPicker.cxx | 19 +++----------------
1 file changed, 3 insertions(+), 16 deletions(-)
New commits:
commit 90e33df14a1bdff55c4759102658dba7510a733a
Author: Stephan Bergmann <sberg...@redhat.com>
AuthorDate: Wed Aug 28 09:49:01 2019 +0200
Commit: Stephan Bergmann <sberg...@redhat.com>
CommitDate: Wed Aug 28 10:59:56 2019 +0200
Always using translateToInternal should be fine in
SalGtkPicker::uritounicode
When SalGtkPicker::uritounicode was originally introduced in
27994c3831e55174af313e74e09905003ff34440 "INTEGRATION: CWS cmcfixes4:
#i46017#
to and from system locale encoding when url is file:///", it only contained
the
g_filename_from_uri code and no translateToInternal fallback (though the
SalGtkPicker::unicodetouri counterpart, already introduced then, only used
INetURLObject::getExternalURL, the precursor to today's translateToExternal,
from the beginning). The translateToInternal fallback was only added later
with e68b4920b0a726578094013b819b1e0833929acb "INTEGRATION: CWS
c07v007_SRC680:
#b6465588# cope with URI encoded in non UTF8 encoding".
But I see no reason to not always use just translateToInternal in
uritounicode
(matching the translateToExternal in unicodetouri). Trying with both
LC_ALL=en_US.UTF-8 and LC_ALL=en_US.ISO-8859-1 and the gtk3 VCL plugin (on
GTK 3.24.10), the only difference between using the g_filename_from_uri and
the
translateToInternal code is that the former produces an IURI sURL where non-
ASCII Unicode characters are written as such (later on in the LO code to be
encoded as %XX...), whereas the latter produces an sURL where those
non-ASCII
Unicode characters are already encoded as %XX...
One difference is for filenames containing bytes that cannot be represented
in
the current LC_CTYPE encoding. g_filename_from_uri reports them as
U+FFFD REPLACEMENT CHARACTER, so producing an IURI sURL containing "�"
(that is
later on in the LO code encoded as %EF%BF%BD), while translateToInternal
keeps
the single %XX representing the original byte intact. (And even though LO
can't
properly handle such a file URL with non--UTF-8 payload, this change is a
small-
step win of keeping the URL at least intact and not garbling it completely
with
"�" aka %EF%BF%BD).
Change-Id: If27fc64c75e986dbb467e147a7e43df3a01db640
Reviewed-on: https://gerrit.libreoffice.org/78216
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sberg...@redhat.com>
diff --git a/vcl/unx/gtk/fpicker/SalGtkPicker.cxx
b/vcl/unx/gtk/fpicker/SalGtkPicker.cxx
index 01671fb1afc6..3e443ea04692 100644
--- a/vcl/unx/gtk/fpicker/SalGtkPicker.cxx
+++ b/vcl/unx/gtk/fpicker/SalGtkPicker.cxx
@@ -56,22 +56,9 @@ OUString SalGtkPicker::uritounicode(const gchar* pIn)
{
// all the URLs are handled by office in UTF-8
// so the Gnome FP related URLs should be converted accordingly
- gchar *pEncodedFileName = g_filename_from_uri(pIn, nullptr, nullptr);
- if ( pEncodedFileName )
- {
- OUString sEncoded(pEncodedFileName, strlen(pEncodedFileName),
- osl_getThreadTextEncoding());
- g_free (pEncodedFileName);
- INetURLObject aCurrentURL(sEncoded, FSysStyle::Unix);
- aCurrentURL.SetHost(aURL.GetHost());
- sURL = aCurrentURL.getExternalURL();
- }
- else
- {
- OUString aNewURL = uri::ExternalUriReferenceTranslator::create(
m_xContext )->translateToInternal(sURL);
- if( !aNewURL.isEmpty() )
- sURL = aNewURL;
- }
+ OUString aNewURL = uri::ExternalUriReferenceTranslator::create(
m_xContext )->translateToInternal(sURL);
+ if( !aNewURL.isEmpty() )
+ sURL = aNewURL;
}
return sURL;
}
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
