Problems with korean symbols in file path

I have a Windows application written in LabVIEW, where path arguments are passed to a DLL which uses Qt. Inside the DLL, I create a QString (passing the char* from LabVIEW to the constructor) to open a QFile.

When the path contains Korean symbols, conversion to QString seems to fail in some way. I added

Code:

---

QTextCodec* codec = QTextCodec::codecForName("EUC-KR");
QTextCodec::setCodecForCStrings(codec);

---

and also tried

Code:

---

QTextCodec* codec = QTextCodec::codecForName("UTF-8");
QTextCodec::setCodecForCStrings(codec);

---

before using QString::QString(const char*), but the problems remain. The first try returns a 0-codec (not found), the second try still fails to convert.

I also tried using QString::fromLocal8Bit(), but even on my english machine this returns a string of size zero. Maybe something to do with the '\' character in the path?

On the National Instruments forum (LabVIEW) I got the following reply concerning the way LabVIEW passes the string to my DLL:

Quote:

---

I don't think that we reinterpret your string in anyway, just reformat the data so that it can be passed to your dll.

So assuming you are getting text from, say, keyboard editing, the text should be in the ANSI codepage that the system is running under. That is, if you are running Windows using an English locale, it will be codepage 1252 (Windows Western, Latin 1), if you are running Windows with a Korean codepage iirc it will be codepage 949, Unified Hangul code.

If you are filling the string with data that you get from an instrument or some other fashion, it could really be anything.

Here is a list of the codepages that Windows knows about

http://msdn2.microsoft.com/en-us/lib...46(VS.85).aspx


I do have some experience with Qt as well, and I think that the function you are looking for to create, say, a QString from this is:

QString::fromLocal8Bit

but I am not 100% certain about this as I am not a Qt expert.

Jeff Peters
LabVIEW R & D

---

The important thing to note here is everything worked fine when I used fopen (C) or std streams instead of Qt to read the files. I changed them to QDataStreams because of some advantages and would not like to go back in time. But it also means something must be happening in the part where the QString is created from my char*, and not earlier.

The LabView people are correct - oyu have to find out the system locale and then convert it to unicode with the help of QTextCodec::convertToUnicode()

QString::QString(const char*) converts from ascii (take a look in the docs !)

That's a good remark, I kept on using ASCII combined with different codecs, not really knowing what was going wrong.

So is this what I need to do? I would like to check with you guys first, otherwise I need to keep on sending test files to Korea :). It works on my system, but no idea what it will be there.

Code:

---

const char* c_str = ...; //Coming from LabVIEW
QTextCodec* codec = QTextCodec::codecForLocale();		
QString converted = codec->toUnicode(c_str, strlen(c_str), 0);

---

Also, I was wondering if you need to include any additional files on deployment to have access to all codecs. For example, when I use QTextCodec::codecForName("EUC-KR") in a Qt program, a successful codec is returned. If I do the same in my LabVIEW controlled DLL, 0 is returned.

Some codec are only available as plugins - see documentation how to deploy them and also take a look into qt-4/plugins/codecs

Shouldn't QString::fromLocal8Bit() always do the trick? Because this seems to do the same: take an 8 bit string and convert it to Unicode based on the locale.

I made a stupid mistake there, I used :

Code:

---

QString string;
string.fromLocal8Bit("something");

---

instead of

Code:

---

QString string = QString::fromLocal8Bit("something");

---

Nevermind about that last question, looking in the source code already answered my question :). So fromLocal8Bit should in fact to the trick and is just retrieving the local Text Codec and performing To Unicode.