Win32/64技術 001 マルチバイト文字列→ワイド文字列変換 - 版の履歴

2024年1月24日 (水) 15:13にYo-netによる

2024-01-24T15:13:45Z

← 古い版		2024年1月25日 (木) 00:13時点における版
4行目:		4行目:

	== '''概要''' ==		== '''概要''' ==
	C++でマルチバイト文字列をワイド文字列に変換する手法についてです。		C++(Cpp)でマルチバイト文字列をワイド文字列に変換する手法についてです。

Yo-net: /* 概要 */

2024-01-24T15:05:39Z

概要

← 古い版		2024年1月25日 (木) 00:05時点における版
4行目:		4行目:

	== '''概要''' ==		== '''概要''' ==
	~~マルチバイト文字列をワイド文字列に変換する手法についてです。~~		C++でマルチバイト文字列をワイド文字列に変換する手法についてです。

Yo-net: /* 概要 */

2023-11-29T14:20:34Z

概要

← 古い版		2023年11月29日 (水) 23:20時点における版
29行目:		29行目:


			=== MultiByteToWideChar ===
	'''<span style="color:darkred;">■MultiByteToWideChar(UINT, DWORD, LPCCH, int, LPWSTR, int)</span>'''		'''<span style="color:darkred;">■MultiByteToWideChar(UINT, DWORD, LPCCH, int, LPWSTR, int)</span>'''

2023年11月8日 (水) 09:21にYo-netによる

2023-11-08T09:21:08Z

← 古い版		2023年11月8日 (水) 18:21時点における版
1行目:		1行目:
	[[Win32/64_アプリケーション開発#処理技術\|Win32/64_アプリケーション開発]]に戻る。		[[Win32/64_アプリケーション開発#処理技術\|Win32/64_アプリケーション開発]]に戻る。

			次の記事：[[Win32/64技術 002 WinUser.hファイルを読み込んでもGWL_HINSTANCEが使えない]]

	== '''概要''' ==		== '''概要''' ==
83行目:		85行目:



			次の記事：[[Win32/64技術 002 WinUser.hファイルを読み込んでもGWL_HINSTANCEが使えない]]

	[[Win32/64_アプリケーション開発#処理技術\|Win32/64_アプリケーション開発]]に戻る。		[[Win32/64_アプリケーション開発#処理技術\|Win32/64_アプリケーション開発]]に戻る。

Yo-net: /* 概要 */

2023-10-31T14:28:01Z

概要

← 古い版		2023年10月31日 (火) 23:28時点における版
31行目:		31行目:
	'''第1引数：''' UINT CodePage		'''第1引数：''' UINT CodePage

	文字コードの変換もできます。この関数では元の文字コードを指定します。この変換では規模の小さいコードセットであるSJIS系から大規模なコードセットUTF-~~16への変換によく使われますので、変換先が無いということにはならないです。逆変換のときはUTF~~-16から任意の文字コードに変換出来ます。VisualStudioは主にShiftJISで処理されています。MicrosoftのShiftJISである932を指定しないと、文字化けが発生します。変換後はワイド文字はUTF-16を使います。UTF-8は可変バイトの1バイトか3バイトで主に表され、ごく稀に4バイトになります。UTF-16も万能ではありません。サロゲートペアを駆使しないとU+10000以降の文字は表せません。例えばU+13001を表現したいときは、0xD830 0xDC01 となります。ユニコード値から10000を引いて3001ですから、0xD8に続けて3001の上位8バイト30を挿入し、0xDCの後ろに下位8バイトの01を挿入します。これがサロゲートペアね。UTF-32こそが全ての文字をそのまま表せる4バイト文字の集まりなのです。万能は言い過ぎたわ。容量は喰いますからね。それにUTF-32に対応したエディタはほぼ存在しません。char型でデバッグ時にも変数にカーソルを当てて表示されるポップアップのクイックウォッチでも文字化けが発生しますし、開発期間中はマルチバイト文字は932文字コードセットの範囲で試すのがおすすめだな。でも意識出来ないんなら危険な使い方ですね。変数の内容を確認するデバッグビューにある自動、ローカル、クイックタブでも文字化けした状態になります。主にCP_UTF8を使う場合はVisualStudioの設定を変更しないといけませんかね。そんなやり方があるのかさえ知りませんけど。今度暇な時にでも調べてみるかな。ファイルに出力したり、試しにUTF-8が元々の値として確かめる場合はリテラルはu8プレフィックス使ったりするんでしょう。ShiftJISだけでは、表現できない文字はありますからね。ファイルにそのまま出力して、UTF-8の文字コードを閲覧できるビューワで開くといった作業が必要です。WindowsもUTF-8を標準にしたらいいのにとも思いますがUTF-8はほぼ3バイト文字になるのでハードディスクの空き容量減るかも知れませんね。Microsoftも簡単には舵を切れないところなのかな。		文字コードの変換もできます。この関数では元の文字コードを指定します。この変換では規模の小さいコードセットであるSJIS系から大規模なコードセットUTF-16への変換によく使われますので、変換先が無いということにはならないです。[[Win32/64技術 003 ワイド文字列→マルチバイト文字列変換\|逆変換]]のときはUTF-16から任意の文字コードに変換出来ます。VisualStudioは主にShiftJISで処理されています。MicrosoftのShiftJISである932を指定しないと、文字化けが発生します。変換後はワイド文字はUTF-16を使います。UTF-8は可変バイトの1バイトか3バイトで主に表され、ごく稀に4バイトになります。UTF-16も万能ではありません。サロゲートペアを駆使しないとU+10000以降の文字は表せません。例えばU+13001を表現したいときは、0xD830 0xDC01 となります。ユニコード値から10000を引いて3001ですから、0xD8に続けて3001の上位8バイト30を挿入し、0xDCの後ろに下位8バイトの01を挿入します。これがサロゲートペアね。UTF-32こそが全ての文字をそのまま表せる4バイト文字の集まりなのです。万能は言い過ぎたわ。容量は喰いますからね。それにUTF-32に対応したエディタはほぼ存在しません。char型でデバッグ時にも変数にカーソルを当てて表示されるポップアップのクイックウォッチでも文字化けが発生しますし、開発期間中はマルチバイト文字は932文字コードセットの範囲で試すのがおすすめだな。でも意識出来ないんなら危険な使い方ですね。変数の内容を確認するデバッグビューにある自動、ローカル、クイックタブでも文字化けした状態になります。主にCP_UTF8を使う場合はVisualStudioの設定を変更しないといけませんかね。そんなやり方があるのかさえ知りませんけど。今度暇な時にでも調べてみるかな。ファイルに出力したり、試しにUTF-8が元々の値として確かめる場合はリテラルはu8プレフィックス使ったりするんでしょう。ShiftJISだけでは、表現できない文字はありますからね。ファイルにそのまま出力して、UTF-8の文字コードを閲覧できるビューワで開くといった作業が必要です。WindowsもUTF-8を標準にしたらいいのにとも思いますがUTF-8はほぼ3バイト文字になるのでハードディスクの空き容量減るかも知れませんね。Microsoftも簡単には舵を切れないところなのかな。

Yo-net: /* 概要 */

2023-10-31T14:03:04Z

概要

← 古い版		2023年10月31日 (火) 23:03時点における版
39行目:		39行目:


	*MB_PRECOMPOSED (0x0001): 正準分解形ではなく、eの上にアクセント´が付いたりするようなéといった合成済み文字を返します。合成済み文字は、文字の形を正準分解形よりも既定で合成された形にします。		*MB_PRECOMPOSED (0x0001): 正準分解形ではなく、eの上にアクセント´が付いたりするようなéといった合成済み文字を返します。例えばSJISのéは0x82 0xA0で、UTF-8では0xC3 0xA9表されますが、これが変換後は合成済みのUTF-16形式0x00E9を得るということになります。


	*MB_COMPOSITE (0x0002): 文字列を正準分解形ではなく合成済み文字で返します。正準分解形とは、複数の合成可能な文字から構成された文字をそれらの基本的な形に変換するものです。		*MB_COMPOSITE (0x0002): 文字列を正準分解形で得ます。例えばSJISのéは0x82 0xA0で、UTF-8では0xC3 0xA9表されますが、これが変換後は正準分解形のUTF-16形式0x0065(e) 0x0301(´)を得るということになります。正準分解形も合成済み文字どちらもéを表す文字です。内部でのバイトコードの持ち方がことなるということです。主にMB_PRECOMPOSEDが使われるそうです。


	*MB_USEGLYPHCHARS (0x0004): ~~一般的な標準文字（GLYPHCHAR）を使用するためのものです。これにより、標準文字として扱われる特定の文字を返します。~~		*MB_USEGLYPHCHARS (0x0004): 変換できなかったときに一般的な標準文字（GLYPHCHAR）、例えば ? のようなものを使用するためのものです。これにより、エラーが発生しても標準文字として扱われる特定の文字を返します。

Yo-net: /* 概要 */

2023-10-31T09:58:00Z

概要

← 古い版		2023年10月31日 (火) 18:58時点における版
38行目:		38行目:
	変換の種類を示すフラグ。		変換の種類を示すフラグ。

	MB_PRECOMPOSED (0x0001): 正準分解形ではなく、eの上にアクセント´が付いたりするようなéといった合成済み文字を返します。合成済み文字は、文字の形を正準分解形よりも既定で合成された形にします。

	~~MB_COMPOSITE~~ (~~0x0002~~): 文字列を正準分解形ではなく合成済み文字で返します。正準分解形とは、複数の合成可能な文字から構成された文字をそれらの基本的な形に変換するものです。		*MB_PRECOMPOSED (0x0001): 正準分解形ではなく、eの上にアクセント´が付いたりするようなéといった合成済み文字を返します。合成済み文字は、文字の形を正準分解形よりも既定で合成された形にします。

	~~MB_USEGLYPHCHARS (0x0004): 一般的な標準文字（GLYPHCHAR）を使用するためのものです。これにより、標準文字として扱われる特定の文字を返します。~~

	~~MB_ERR_INVALID_CHARS~~ (~~0x0008~~): ~~無効な文字（マルチバイト文字として表現できない文字）が見つかった場合にエラーを発生させます。~~		*MB_COMPOSITE (0x0002): 文字列を正準分解形ではなく合成済み文字で返します。正準分解形とは、複数の合成可能な文字から構成された文字をそれらの基本的な形に変換するものです。

	~~MB_PRECOMPOSED \| MB_ERR_INVALID_CHARS (0x0009)の2つのフラグを組み合わせたもの:無効な文字の検出と合成済み文字の使用が可能になります。~~

	MB_COMPOSITE \| MB_ERR_INVALID_CHARS (0x0010)の合成済み文字と無効な文字の検出を組み合わせたもの:		*MB_USEGLYPHCHARS (0x0004): 一般的な標準文字（GLYPHCHAR）を使用するためのものです。これにより、標準文字として扱われる特定の文字を返します。


			*MB_ERR_INVALID_CHARS (0x0008): 無効な文字（マルチバイト文字として表現できない文字）が見つかった場合にエラーを発生させます。


			*MB_PRECOMPOSED \| MB_ERR_INVALID_CHARS (0x0009)の2つのフラグを組み合わせたもの:無効な文字の検出と合成済み文字の使用が可能になります。


			*MB_COMPOSITE \| MB_ERR_INVALID_CHARS (0x0010)の合成済み文字と無効な文字の検出を組み合わせたもの:

Yo-net: /* 概要 */

2023-10-31T09:54:40Z

概要

← 古い版		2023年10月31日 (火) 18:54時点における版
37行目:		37行目:

	変換の種類を示すフラグ。		変換の種類を示すフラグ。

			MB_PRECOMPOSED (0x0001): 正準分解形ではなく、eの上にアクセント´が付いたりするようなéといった合成済み文字を返します。合成済み文字は、文字の形を正準分解形よりも既定で合成された形にします。

			MB_COMPOSITE (0x0002): 文字列を正準分解形ではなく合成済み文字で返します。正準分解形とは、複数の合成可能な文字から構成された文字をそれらの基本的な形に変換するものです。

			MB_USEGLYPHCHARS (0x0004): 一般的な標準文字（GLYPHCHAR）を使用するためのものです。これにより、標準文字として扱われる特定の文字を返します。

			MB_ERR_INVALID_CHARS (0x0008): 無効な文字（マルチバイト文字として表現できない文字）が見つかった場合にエラーを発生させます。

			MB_PRECOMPOSED \| MB_ERR_INVALID_CHARS (0x0009)の2つのフラグを組み合わせたもの:無効な文字の検出と合成済み文字の使用が可能になります。

			MB_COMPOSITE \| MB_ERR_INVALID_CHARS (0x0010)の合成済み文字と無効な文字の検出を組み合わせたもの:

Yo-net: /* 概要 */

2023-10-31T09:00:33Z

概要

← 古い版		2023年10月31日 (火) 18:00時点における版
31行目:		31行目:
	'''第1引数：''' UINT CodePage		'''第1引数：''' UINT CodePage

	~~文字コードの変換もできます。この関数では元の文字コードを指定します。逆変換のときはUTF~~-16から任意の文字コードに変換出来ます。VisualStudioは主にShiftJISで処理されています。MicrosoftのShiftJISである932を指定しないと、文字化けが発生します。変換後はワイド文字はUTF-16を使います。UTF-8は可変バイトの1バイトか3バイトで主に表され、ごく稀に4バイトになります。UTF-16も万能ではありません。サロゲートペアを駆使しないとU+10000以降の文字は表せません。例えばU+13001を表現したいときは、0xD830 0xDC01 となります。ユニコード値から10000を引いて3001ですから、0xD8に続けて3001の上位8バイト30を挿入し、0xDCの後ろに下位8バイトの01を挿入します。これがサロゲートペアね。UTF-32こそが全ての文字をそのまま表せる4バイト文字の集まりなのです。万能は言い過ぎたわ。容量は喰いますからね。それにUTF-32に対応したエディタはほぼ存在しません。char型でデバッグ時にも変数にカーソルを当てて表示されるポップアップのクイックウォッチでも文字化けが発生しますし、開発期間中はマルチバイト文字は932文字コードセットの範囲で試すのがおすすめだな。でも意識出来ないんなら危険な使い方ですね。変数の内容を確認するデバッグビューにある自動、ローカル、クイックタブでも文字化けした状態になります。主にCP_UTF8を使う場合はVisualStudioの設定を変更しないといけませんかね。そんなやり方があるのかさえ知りませんけど。今度暇な時にでも調べてみるかな。ファイルに出力したり、試しにUTF-8が元々の値として確かめる場合はリテラルはu8プレフィックス使ったりするんでしょう。ShiftJISだけでは、表現できない文字はありますからね。ファイルにそのまま出力して、UTF-8の文字コードを閲覧できるビューワで開くといった作業が必要です。WindowsもUTF-8を標準にしたらいいのにとも思いますがUTF-8はほぼ3バイト文字になるのでハードディスクの空き容量減るかも知れませんね。Microsoftも簡単には舵を切れないところなのかな。		文字コードの変換もできます。この関数では元の文字コードを指定します。この変換では規模の小さいコードセットであるSJIS系から大規模なコードセットUTF-16への変換によく使われますので、変換先が無いということにはならないです。逆変換のときはUTF-16から任意の文字コードに変換出来ます。VisualStudioは主にShiftJISで処理されています。MicrosoftのShiftJISである932を指定しないと、文字化けが発生します。変換後はワイド文字はUTF-16を使います。UTF-8は可変バイトの1バイトか3バイトで主に表され、ごく稀に4バイトになります。UTF-16も万能ではありません。サロゲートペアを駆使しないとU+10000以降の文字は表せません。例えばU+13001を表現したいときは、0xD830 0xDC01 となります。ユニコード値から10000を引いて3001ですから、0xD8に続けて3001の上位8バイト30を挿入し、0xDCの後ろに下位8バイトの01を挿入します。これがサロゲートペアね。UTF-32こそが全ての文字をそのまま表せる4バイト文字の集まりなのです。万能は言い過ぎたわ。容量は喰いますからね。それにUTF-32に対応したエディタはほぼ存在しません。char型でデバッグ時にも変数にカーソルを当てて表示されるポップアップのクイックウォッチでも文字化けが発生しますし、開発期間中はマルチバイト文字は932文字コードセットの範囲で試すのがおすすめだな。でも意識出来ないんなら危険な使い方ですね。変数の内容を確認するデバッグビューにある自動、ローカル、クイックタブでも文字化けした状態になります。主にCP_UTF8を使う場合はVisualStudioの設定を変更しないといけませんかね。そんなやり方があるのかさえ知りませんけど。今度暇な時にでも調べてみるかな。ファイルに出力したり、試しにUTF-8が元々の値として確かめる場合はリテラルはu8プレフィックス使ったりするんでしょう。ShiftJISだけでは、表現できない文字はありますからね。ファイルにそのまま出力して、UTF-8の文字コードを閲覧できるビューワで開くといった作業が必要です。WindowsもUTF-8を標準にしたらいいのにとも思いますがUTF-8はほぼ3バイト文字になるのでハードディスクの空き容量減るかも知れませんね。Microsoftも簡単には舵を切れないところなのかな。

2023年10月31日 (火) 08:49にYo-netによる

2023-10-31T08:49:03Z

← 古い版		2023年10月31日 (火) 17:49時点における版
20行目:		20行目:

	int iwcharLen = MultiByteToWideChar(932, 0, stringSJISstr.c_str(), -1, nullptr, 0);		int iwcharLen = MultiByteToWideChar(932, 0, stringSJISstr.c_str(), -1, nullptr, 0);
	std::wstring wstringUTF16str(iwcharLen);		std::wstring wstringUTF16str(iwcharLen, 0);
	MultiByteToWideChar(932, 0, stringSJISstr.c_str(), -1, &wstringUTF16str[0], iwcharLen);		MultiByteToWideChar(932, 0, stringSJISstr.c_str(), -1, &wstringUTF16str[0], iwcharLen);
	</syntaxhighlight>		</syntaxhighlight>