9

私の Win32 Delphi アプリは、Unicode をサポートしない他のアプリケーションによって生成されたテキスト ファイルを分析します。したがって、私のアプリは ansi 文字列を読み書きする必要がありますが、GUI で Unicode を使用して、よりローカライズされたユーザー エクスペリエンスを提供したいと考えています。このアプリは、TList から派生したオブジェクト内の文字列のかなり重い文字ごとの分析を行います。

Delphi 2006 から Delphi 2009 に移行する際に Unicode GUI に移行する際に、次のことを計画する必要があります。

  1. ansistring ファイル I/O を除いて、アプリ内で完全に Unicode に移行しますか?
  2. ansistring を処理するコードをカプセル化します (つまり、内部的に ansistring として処理し続けます)。

真に詳細な回答を得るには、かなりの量のコードが必要になることを認識しています。この移行を行い、まだプレーン テキスト ファイルで作業しなければならない人々からの印象について尋ねているだけです。ansistrings と Unicode の間の障壁をどこに置くか?

編集: #1 の場合、ansistring 出力用に Unicode 文字列をマッピングするための提案はありますか? 入力文字列の変換は、tstringlist.loadfromfile (たとえば) を使用して自動的に行われると思います。

4

4 に答える 4

4

AnsiString 出力のようなものはありません。すべてのテキスト ファイルには文字エンコーディングがあります。ファイルに ASCII 範囲外の文字が含まれている場合は、エンコーディングについて考える必要があります。Unicode エンコーディングを使用していない限り、異なる国でこれらのファイルをロードしても結果が異なるためです。

テキスト ファイルをロードする場合、そのファイルのエンコーディングを知る必要があります。xml や html などの形式の場合、その情報はテキストの一部です。Unicode の場合はBOMがありますが、UTF-8 でエンコードされたファイルには厳密には必要ありません。

アプリケーションを Delphi 2009 に変換することは、テキスト ファイルのエンコーディングについて考え、過去の間違いを修正するチャンスです。アプリケーションのデータ ファイルは、多くの場合、アプリケーション自体よりも寿命が長いため、データ ファイルを将来にわたって使用できるようにする方法とユニバーサルにする方法を検討する価値があります。すべての新しいアプリケーションのテキスト ファイル エンコーディングを UTF-8 にすることをお勧めします。そうすれば、アプリケーションを異なるプラットフォームに簡単に移植できます。UTF-8 はデータ交換に最適なエンコーディングであり、ASCII または ISO8859-1 範囲の文字の場合、UTF-16 または UTF-32 よりもはるかに小さなファイルを作成します。

データ ファイルに ASCII 文字のみが含まれている場合は、有効な UTF-8 エンコード ファイルであるため、すべて設定されています。データ ファイルが ISO8859-1 エンコーディング (またはその他の固定エンコーディング) である場合、それらを文字列リストにロードして保存し直すときに、一致する変換を使用します。どのエンコーディングが使用されるか事前にわからない場合は、読み込み時にユーザーに尋ねるか、デフォルトのエンコーディングのアプリケーション設定を提供してください。

内部で Unicode 文字列を使用します。処理する必要があるデータの量によっては、UTF-8 でエンコードされた文字列を使用する場合があります。

于 2009-06-17T04:13:55.883 に答える
4

労力と要件に見合うだけの価値がある場合は、完全なユニコードにすることをお勧めします。また、ANSI ファイル I/O を残りの部分から分離しておきます。ただし、これはアプリケーションに大きく依存します。

于 2009-06-17T02:45:48.280 に答える
3

あなたは言う：

「このアプリは、TList から派生したオブジェクト内の文字列のかなり重い文字ごとの分析を行います。」

Windows はネイティブで Unicode を実行するため、テキスト ファイルを内部で Unicode としてロードすると、文字分析がより高速に実行されることがあります。

一方、大きなファイルの場合は、2 倍のメモリを必要とすることもわかります。

詳細については、Jan Goyvaert の記事「ネイティブ Win32 文字列型を使用した速度の利点」を参照してください。

したがって、それはあなたが決定しなければならないトレードオフです。

于 2009-06-17T04:26:51.190 に答える
1

GUI から Unicode 入力を取得する場合、それを ASCII 出力に変換するための戦略は何ですか? (これは、Ansi テキストを元に戻すと言及した場合の想定です。おそらく、これらの非 Unicode ベースのアプリケーションは、書き換える予定がなく、ソースコードを持っていないと想定されます。) アプリ全体で AnsiString を使用することをお勧めします。これらの他のアプリが Unicode 対応になるまで。アプリケーションの主な仕事が非 Unicode ASCII タイプのファイルの分析である場合、なぜ内部的に Unicode に切り替えるのでしょうか? アプリケーションの主な仕事が、より優れた Unicode 対応 GUI を使用することである場合は、Unicode を使用してください。適切な選択を決定するのに十分な情報が提示されているとは思えません。

これらの非 Unicode アプリケーションで簡単に変換できない文字が書き戻される可能性がない場合は、UTF-8 の提案が有効な方法です。ただし、可能であれば、非 Unicode アプリケーションはマルチバイト文字をどのように処理するのでしょうか? (おそらく) 基本的な ASCII 文字セットにどのように変換しますか?

于 2009-06-17T05:02:11.713 に答える