0

アプリケーションをCentOS6からMacOSXに移植しています。これはiconvに依存し、CentOSで正常に動作します。ただし、MacOSXではそうではありません。次の動作が見られます。

const char *codePages[] = { "MAC", "LATIN1", "ISO_8859-1", "WINDOWS-1252", "ASCII" };
int codePagesCount = 5;
iconv_t converter1 = iconv_open("UTF-32", codePages[0]);// Works
if(converter1 != (iconv_t)-1)
   iconv_close(converter1);
iconv_t converter2 = iconv_open("UTF−32", "MAC");// Fails, returns -1
if(converter2 != (iconv_t)-1)
   iconv_close(converter2);

このコードは些​​細なことのように見えます。最初のiconv_openはコンバーターを作成し、codePages配列からコードページ名を取得します。そのゼロ要素はMACであるため、MacOSXが独自のコードページからUnicodeへの変換をサポートする必要があることは論理的です。そして、iconv_openへの最初の呼び出しは機能します。ただし、iconv_openへの2回目の呼び出しは同じことを行います。また、MacエンコーディングからUnicodeへのコンバーターを作成します。そして、何らかの理由で失敗し、-1を返します。同じ引数（1つはハードコードされた配列の要素、もう1つはハードコードされた文字列）で同じ関数を呼び出すと、最初の呼び出しで通常の機能が発生し、2番目の呼び出しで失敗する場合、このような状況の理由は何でしょうか。

4

1 に答える 1

1

2番目の「UTF-32」は最初のものと同じではありません.最初のものは単純なマイナス記号を使用していますが、2番目のものはエンダッシュを使用しています.

于 2012-10-04T12:11:39.560 に答える