ReadFile funcによる文字列の扱いについて

Question

前提・実現したいこと

WinAPIでファイルオープンして文字列を取り出しiostreamを使って吐き出そうとしています。

該当のソースコード

#define UNICODE
using namespace std;

#include <iostream>
#include <Windows.h>

HANDLE file;
//const wchar_t filename[]=L"15116020_le.csv";
const wchar_t filename[] = L"test.txt";
LPWSTR lpszbuf;
DWORD accbytes;
HGLOBAL hMemory;


int main(void) {
	
	file = CreateFile(filename, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

	hMemory = GlobalAlloc(GHND, GetFileSize(file, NULL) + sizeof(wchar_t));

	if (hMemory == NULL) {
		cout << L"Failes to get memory" << endl;
	}
	lpszbuf = (LPTSTR)GlobalLock(hMemory);

	if (ReadFile(file, lpszbuf, GetFileSize(file, NULL), &accbytes, NULL) != 0)
	{
		lpszbuf[accbytes] = '\0';
		cout << L"FileRead Successed" << endl;
		cout << lpszbuf << endl;
	}

	CloseHandle(file);
	GlobalUnlock(hMemory);
	GlobalFree(hMemory);

	return 0;
}

質問

lpszbufはポインターなのでしょうか？
確保した文字列がメモリ上で断続的だった場合の文字列はどうやって取り出せるのでしょうか？
取り出した値はバイナリになりますか？バイナリならどうやってUNICODE等に変換できるのでしょうか？
あとコード上で使い方がおかしいものがあったらご指摘ください。

【追記】得たバイナリをwcoutで吐き出すためにはどう記述するのが正しいのでしょうか

補足情報

Visual C++
VisualStudio 2017 Community
Windows10 Pro
メモリ:16GB

Answer 1

ご質問に順番に回答させていただきます。

---

lpszbuf はポインターなのでしょうか？

ポインターです。LPWSTR は、wchar_t* をtypedef したものです。(実際はもう少しややこしいですが)
Windows Data Types
SDKのヘッダーファイル winnt.h に定義があると思いますので、そちらも見てみましょう。

---

確保した文字列がメモリ上で断続的だった場合の文字列はどうやって取り出せるのでしょうか？

データ構造によりますが、自分でがんばって探し、取り出すしか無いと思います。

---

取り出した値はバイナリになりますか？バイナリならどうやってUNICODE等に変換できるのでしょうか？

ReadFileでファイルに書いてある内容そのままで指定のメモリに読み出しますので、その文字列のデータがシフトJISなり、ただのASCIIコードなり、UNICODEでないならば、プログラマー自身が変換する必要があります。

ネイティブのAPIとしてはWideCharToMultiByteやMultiByteToWideCharの文字コード変換用APIがありますが、勉強を目的とする以外でこれらを直接使うことは今ではほとんど無いと思います。もっと便利な方法があります。
方法: さまざまな文字列型間で変換する
WideCharToMultiByteらの意味を理解したならば、これらの便利なものを使うことも検討しましょう。

---

あとコード上で使い方がおかしいものがあったらご指摘ください。

そうですね、気がついたものとしては

• HANDLE fileやLPWSTR lpszbufがグローバル変数である必然性が無い。
• LPTSTR(TCHAR配列のポインター)とLPWSTR(WCHAR/wchar_t配列のポインター)の意識が混在している。※TCHARはマルチバイト(_MBCS)とUNICODE(_UNICODE)の双方で同じコードで書くためのものです。
• ReadFile の返り値はBOOL なので、 実行結果の判定として != 0は不適切。
• GlobalAlloc(GHND...)～GlobalLock～ GlobakUnlock～GlobaFree の一連の流れは作法としては正しいのですが、短期間であるならば、Cランタイムのmalloc～freeで充分かと思います。GHNDフラグ(GMEM_MOVEABLE|GMEM_ZEROINIT)を指定したGlobalAllocの使用は、昔、PCのメモリが少なかった頃に有用だったもので、現在のPC+普通のアプリケーションで厳密に使い分けるほどに有用なものでもありません。

あと、問題がある部分としては

• GlobalAllocで取得したhMemoryがNULLであった場合でも、処理を続行している。
• ReadFile実行後、lpszbuf[accbytes] = '\0'; でNULL文字を埋め込んでいるが、lpszbufはwchar_t型のポインターなので、実際に読み込んだバイト長 * 2 の位置に'\0'を挿入してしまっている。（メモリを破壊している) また、L'\0' との表記の方がより適切。
• coutを使う部分ですが、cout ではLで指定したワイド文字列(UNICODE)は出力できないです。wcout を使う必要があります。

---

です。

Comments

[Weapon]

細かい説明ありがとうございます。
参考書を読んでそのまま記述したため理解はしていないのですが lpszbuf[accbytes+2] ？にNULLを突っ込むのはなぜなのでしょうか？
あと追記をよろしければお願いします。

[dodox86]

+2ではなく、lpszbuf[accbytes] = '\0';　ですよね？　これは、メモリに読み込んだファイルの内容の末尾に'¥0' を入れることで、確実にNULLで終わる文字列にしているのだと思われます。私もよくやります。
（ファイルのデータ中には末端にNULLが無いので）
ただ、いずれにせよlpszbu[accbytes]はバグです。ポインタの型を考えると、バイト単位でのaccbytesではインデックスが合いません。

[catsforepaw]

Weapon さん
「参考書」がいつの時代のものか知りませんが、相当古いコードです。`GlobalAlloc`関数は16bit時代の遺物であり、限定的な場面(DDEとかクリップボードとか。DDEもすでに遺物化していますが)でしか使う必要性はありませんし、使う意味もありません。メモリの動的確保ならdodox86さんのご指摘のようにmallocを使ってください。どうしてもWindows APIを使いたいのなら`HeapAlloc`を使ってください。
もう少し新しい参考書をご用意された方がよろしいかと思います。

[Weapon]

mallocで動的確保するときどの型で文字列を確保するのがいいのでしょうか？ANSIかUNICODEかはたまたバイナリか変換は後で処理を追加するとして拡張性を持たせたいです。

[dodox86]

文字列の型は考えず、バイト単位で良いのではないでしょうか。mallocもGlobalAllocも、割り当てるサイズをバイト単位で指定するだけで、メモリ中に入れるデータがどのような型かは意識していません。