Just a thought: should we fork QTextCodec as KTextCodec and make our lives simpler in the process?

I think it at the moment is still alive in the Qt5Compat module:

https://code.qt.io/cgit/qt/qt5compat.git/tree/src/core5/codecs?h=6.1

Therefore I would tend to say at least for the internal uses, in e.g. KTextEditor, we can first depend on this and if it goes away or the improvements in core aren't in the way we want, we can still fork it afterwards?

What slightly worries me is the behavior change of QTextStream. In Qt5 it uses QTextCodec::codecForLocale() by default (Which is UTF-8 for me, but no idea how common other values are). If a Qt5 app saves some data using a non-UTF8 codec implicitly we're in for a nasty surprise when the app is ported to Qt6 and starts reading the same data as UTF-8

The locale encoding is always UTF-8 on Unix and some "more local" locale (latin1, koi8-r, etc) on Windows.
So what you described can only happen on Windows. Still bad, of course, for reading existing text files. But the user base isn't exactly as big as on Unix, for KDE software. This is just very surprising overall for Qt on Windows. In the JIRA task you linked, Thiago initially said "QTextStream needs the ability to select between UTF-8 and the locale's 8-bit charset". But you seem to say this didn't happen?

In T14154#250537, @dfaure wrote:

The locale encoding is always UTF-8 on Unix and some "more local" locale (latin1, koi8-r, etc) on Windows.

Is it always the case? Even when I use a locale like zh_CN.gb18030? That would mean https://invent.kde.org/frameworks/kauth/-/blob/master/src/kauthhelpersupport.cpp#L76 is useless

I agree that there is no rush to fork, since stuff in compat libs usually stay available until the next major version release, so qt5combat will probably still be there until Qt 7 (same story with kdelibs4support, right? :))

In T14154#250537, @dfaure wrote:

In the JIRA task you linked, Thiago initially said "QTextStream needs the ability to select between UTF-8 and the locale's 8-bit charset". But you seem to say this didn't happen?

I didn't see it indicated in the API docs, but I haven't looked at the code, so I don't really know

From building against Qt6, one implication of QTextCodec being moved to the Qt5 compat module, is that QTextStream::setCodec() is gone in Qt6, replaced by QTextStream::setEncoding(), which doesn't have the same range of encodings that are available in QTextCodec.

So even if we "fork" QTextCodec into e.g. KCoreAddons, QTextStream won't have QTextCodec support in Qt6. (Maybe that was obvious already for others, but I've only realised this now :-)).

We might need to use QTextCodec in ark to fix this bug: https://bugs.kde.org/show_bug.cgi?id=393901#c12

Basically we would need something like this:

diff --git a/plugins/libzipplugin/libzipplugin.cpp b/plugins/libzipplugin/libzipplugin.cpp
index e9cb49f2..dc6b0ee0 100644
--- a/plugins/libzipplugin/libzipplugin.cpp
+++ b/plugins/libzipplugin/libzipplugin.cpp
@@ -24,6 +24,7 @@
 #include <utime.h>
 #include <zlib.h>
 #include <memory>
+#include <QTextCodec>
 
 K_PLUGIN_CLASS_WITH_JSON(LibzipPlugin, "kerfuffle_libzip.json")
 
@@ -723,7 +724,10 @@ bool LibzipPlugin::extractEntry(zip_t *archive, const QString &entry, const QStr
                 }
                 setPassword(query.password());
 
-                if (zip_set_default_password(archive, password().toUtf8().constData())) {
+                QString pwd = password();
+                QTextCodec *codec = QTextCodec::codecForName("windows-1250");
+                QByteArray encodedString = codec->fromUnicode(pwd);
+                if (zip_set_default_password(archive, encodedString.data())) {
                     qCDebug(ARK) << "Failed to set password for:" << entry;
                 }
                 firstTry = false;

Is there any alternative for this job? Can KCodecs convert from UTF-16 to other text encodings?

For now using QTextCodec is fine for that, it's still available in qt5compat

I think from a frameworks POV we can consider this done.

The only usage of QTextCodec I can find in frameworks is internally in KEncodingFileDialog