4

うまくいけば、質問のタイトルが私の問題を十分に説明しています。

プラットフォーム: OSX 10.8、llvm と clang++ コンパイラ

ファイル名が日本語またはキリル文字のディレクトリがあります。これらのファイル名はls、en_EN.UTF-8 ロケールと Monaco 10 フォントを使用する iTerm2 で (たとえば 経由で) 正しく表示されます (ロケール/フォントが違いを生むかどうかはわかりませんが、違いがあるようです)。ただし、UTF-8 をサポートしていないバニラの xterm は、スクランブルされたシンボルまたは「?」を出力します。非 ASCII 文字の文字。

実際の質問は次のとおりです。

C++ プログラムでは、readdir()fromを使用しdirent.hて、日本語またはキリル文字のファイル名を含むディレクトリの内容を一覧表示します。結果のd_nameプロパティを出力すると、Xcode ターミナルに正しい文字が表示されます。つまり、たとえば日本の漢字は実際にそのように表示されます。iTerm2 からプログラムを実行する場合も同様です。繰り返しますが、UFT-8 以外の xterm では文字がスクランブルされています。struct direntreaddir()

  • 日本語のファイル名のバイト サイズは表示される文字数と等しくないため、dirent.h関数は UTF-8 文字列で動作すると思います。すべての OSX C-Library がそのように動作する可能性はありますか?

  • したがって、たとえば、struct dirent.d_nameまたは strcpyそれを変更し、その変更された文字列を使用して新しいファイルを作成しても安全ですか? 「?????」につながる何らかのトラップに足を踏み入れることは可能ですか? 漢字の代わりにファイル名が書かれていますか？

  • "C" などの別のロケールを設定すると、問題が発生します (を使用する場合はそうではないようですsetlocale(LC_ALL,"C"))。

注: 私は、dirent.h に代わるサード パーティの可能性には興味がありません。このプログラムは、OSX がロケールと文字エンコーディングをどのように処理するかを明らかにするためだけに作成しました。

4

2 に答える 2

1

UTF-8 は、従来の文字列処理コードの観点から、ASCII と下位互換性を持つように設計されています。これにはstrcpy()、友人も含まれます。

そうです、あなたのコードでは、これらの文字列を他の文字列*と同じように処理しても安全です。巧妙なことが起こるのは表示時だけです。

* 文字列内の個々の文字をいじらない限り。

于 2013-01-15T12:39:56.590 に答える
1

有効な UTF8 文字列にはヌル文字が含まれていないため、すべての文字列操作は UTF8 でエンコードされた文字列に対して機能する必要があります。ただし、一部の文字は複数のバイトでエンコードされているため、おそらくその部分文字列を取得したり、その中のバイトを変更したりすることは望ましくありません。

処理する API のほとんどはchar*エンコーディングを認識せず、気にしないため、安全に使用できるはずです。

setlocale は、主に文字の種類、順序付け、書式設定に関連する特定の操作に影響します。

文字列を印刷すると、一連のバイトとして出力されます。端末エミュレーターはそれを UTF8 として解釈し、正しい文字を選択します。もちろん、Unicode を認識しない xterm は、Unicode を正しく解釈して適切な文字を表示することができません。

于 2013-01-15T12:41:58.933 に答える