問題タブ [wofstream]

Linux システムで Qt/C++ を使用しています。QLineEditのテキストをに変換してstd::wstringに書き込む必要がありstd::wofstreamます。ASCII 文字列では正しく機能しますが、他の文字 (アラビア語またはウズベク語) を入力すると、ファイルに何も書き込まれません。(ファイルのサイズは 0 バイトです)。

これは私のコードです:

John Smith行編集で入力された出力は ですJohn Smith10。しかし、Unicode 文字列の場合は何もありません。

最初は の問題だと思いましたが、QString::toStdWString()すべてcustomersFile << ws.length();の文字列の正しい長さを書き込みます。したがって、ファイルへの書き込みに何か問題があると思いwstringます。[?]

編集：

日食でまた書きます。g++4.5でコンパイルしました。結果は同じです：

CStdioFileタイプを使用すると、コードをコンパイルできません。afx.hヘッダーファイルをインクルードしましたが、まだエラーが発生します。私がやろうとしているのは、xmlドキュメント全体を含むcstringをファイルに書き込むことです。このcstringにはコメントが含まれていますが、wofstreamなどの他のオブジェクトを使用してファイルに書き込むと、何らかの理由でこれらのコメントが削除されます。そのため、CStdioFileを使用してこれをファイルに書き込もうとしています。CStdioFileを使用してコードをコンパイルできない理由、またはxmlコメントを含むcstringをファイルに書き込む他の方法について誰かが私を助けてくれるなら、私に知らせてください！以下は、CStdioFileを使用した私のコードです。

そして私のエラー：エラーC2065：'CStdioFile'：宣言されていない識別子エラーC2065：'modeCreate'：宣言されていない識別子エラーC2065：'modeWrite'：宣言されていない識別子エラーC2065：'typeText'：宣言されていない識別子エラーC2065：'xmlFile'：宣言されていない識別子エラーC2146：構文エラー：';'がありません 識別子の前'xmlFile'エラーC2228：'.Close'の左側はクラス/構造体/共用体タイプタイプである必要があります''unknown-type''エラーC2228：'.Open'の左側はクラス/構造体/共用体タイプタイプである必要があります'' unknown-type''エラーC2228：'.WriteString'の左側にはクラス/構造体/共用体タイプが必要ですタイプは''unknown-type''エラーC2653：'CFile'：クラスまたは名前空間名ではありませんエラーC2653： 'CFile'：

最初にキリル文字でファイルを読み取り、次にランダムな数の行をランダムに選択して、変更したテキストを別のファイルに書き込む必要があります。ラテン文字には問題ありませんが、ゴミが出るため、キリル文字に問題が発生します。だから、これが私がそのことをやろうとした方法です。

言う、ファイルinput.txtは

私はそれを読んで、すべての行をベクトルに入れる必要があります：

では、シンボルだけでなく、読みやすいものを生成するために、キリル文字をどのように使用できますか？

いくつかのワイド文字をファイルに書き込もうとすると、ファイルへのすべての出力がそれらの文字の後で停止します。何が起こっているのかわかりません。

ワイド文字をファイルに書き込もうとすると、wofstream が切り捨てられます。

ワイド文字をマルチバイトに変換しようとしています。yje myfile の部分だけです。残りは問題なく動作します。いくつかの場所で ofstream を使用しているため、wofstream を使用できないため、これが残っています。

}

Windows (Visual Studio 2008 を使用) および Mac (GCC を使用) 用にビルドされたプログラムで、Boost C++ ライブラリを使用してシリアル化を実装しています。std::wstringこのプログラムは、約 30 のクラスでワイド文字列 ( ) を使用しています。プラットフォームによっては、( を使用してboost::archive::text_woarchive) ファイルに保存すると、出力ファイル内でのワイド文字列の表現が異なります。

Windowsで保存:

MacOSXで保存:

ここで、* は NULL 文字です。

Mac ビルドを使用して Windows で作成されたファイルを読み込もうとすると (逆も同様)、プログラムがクラッシュします。

これまでの私の理解では、Windows はワイド文字あたり 2 バイトをネイティブに使用しますが、MacOSX (および一般的には Unix と思われます) は 4 バイトを使用します。

utf8_codecvt_facet.cpp、UTF8-CPP、ICU、Dinkumwareなどの可能なソリューションに出くわしましたが、既に持っているもので機能する例をまだ見ていません(たとえば、5 か月の連載作業をこの点）：

myMainClassワイド文字列と、シリアル化される他のクラスへの Boost スマート ポインターが含まれています。

別のプロセスでホストされたインターフェイスと Windows RPC メカニズムを介して通信するアプリケーションを作成しています。

マーシャリングは、標準の組み込み NDR によって処理されます。インターフェイスはいくつかの関数を公開しますが、そのうちの 1 つUNICODE_STRINGはパラメーターを介して文字列 ( ) を返します。

この関数は、成功した場合は 0 を返し、それ以外の場合はエラー コードを返します。RPC 関数を呼び出すと、成功し、UNICODE_STRING パラメータが設定されます。

問題は、C++ またはランタイムのいずれかが、関数によって返された文字列を読み取ろうとしているときに発生するエラーを飲み込むことです。多くのコードを読む手間を省くために、私のコードの簡略版を次に示します。

このコードを実行すると、出力は次のようになります。

そして戻ります。私はこの関数をデバッガーでステップ実行しましたが、68 文字全体を正しく処理し (バッファーの内容に関係なく、ガベージ データです)、最後のI won't be writtenwcout 命令に正しくステップインします。コンソールが処理できない判読不能な文字に問題があり、これらの文字が次の文字の動作またはコンソールカーソルを変更する可能性があるかどうか疑問に思いました-それは出力を非表示にしますが、いいえ-出力ストリームを交換して設定しましたファイル (wofstream) に出力し、ファイルのサイズは 47 バイトでした。これは、コンソール ストリームに書き込まれるサイズとまったく同じです。

アクセス違反、例外、ログ エントリなどはありません。デバッガー (VS2010) でさえ、考えられるすべての種類の例外で中断することを選択した後、例外に注意しません。さらに驚くべきことは、デバッガーでコードをステップ実行し、そこでローカルを監視すると、期待値が得られることです (私は 0 から68 に変更され、バッファー内の現在の wchar_t には値 (ガベージ Unicode char) があります。

誰でもこの動作を説明できますか?

編集：

印刷ループを次のように交換します。

67 までの値をtemp正しく出力します。

それでも、これらの文字の wchar_t バージョンを出力すると、出力ストリームが何も受け入れなくなるのはなぜでしょうか?

私は現在、任意のウィンドウでGetWindowTextを呼び出し、後で処理するためにそのデータをファイルに保存する必要があるアプリケーションを作成しています。簡単に言うと、バトルフィールド3でツールが失敗していることに気付き、ウィンドウタイトルの次の文字に問題を絞り込みました： http：//www.fileformat.info/info/unicode/char/2122/index。 htm

そこで、次のことを実行する小さなテストアプリを作成しました。

低く、プログラムの残りの部分でコンソールウィンドウへの出力が途切れるのを見てください。

MessageBoxWなどのAPIが問題なく表示するのに、なぜMSVC STLがこの文字（および他の文字を想定）を窒息させるのですか？

これらの文字をファイルに印刷するにはどうすればよいですか？

Windows7x64のVC10とVC11の両方でテストされています。

ポストの構成が不十分で申し訳ありませんが、ここで髪を引き裂いています。

ありがとう。

編集：

最小限のテストケース

期待される結果：「™」文字がコンソールとファイルに出力されます。観察結果：ファイルは作成されましたが、空です。コンソールへの出力はありません。

コンソールに使用しているフォントが問題の文字を表示できることを確認しました。ファイルは完全に空です（サイズは0バイト）。

編集：

さらにデバッグすると、「failbit」と「badbit」がストリームに設定されていることがわかります。

編集：

また、Boost.Localeを使用してみましたが、すべての標準ストリームにグローバルかつ明示的に組み込まれた新しいロケールでも同じ問題が発生しています。