1

Delphi2006からXEにいくつかの大きなアプリを移植したいと思っています。その理由はUnicodeとはあまり関係がありませんが、（うまくいけば）IDEの安定性の向上、ネイティブPNGのサポート、コンポーネントの増加、VCLのバグの減少、サードパーティのものへの依存の減少、皆さんからのリブの減少などを利用するためです。一部のアプリはUnicodeの恩恵を受ける可能性がありますが、現時点ではそれは問題ではありません。現時点では、それらを再度コンパイルするための最も直接的なルートをたどりたいと思っています。

まず、あいまいな文字列宣言をすべて変更しました。つまり、stringをAnsiStringまたはShortStringに、charをAnsiCharに、pCharをpAnsiCharに変更し、D2006で再コンパイルしました。ここまでは順調ですね。何も壊れませんでした。

私の質問は：ここからどこへ？ソースをXEコンパイラに提示し、タッチペーパーに光を当てると仮定すると、大きな問題になる可能性が高いのは何ですか？

例えば、 

var
    S : AnsiString ; 
...
MainForm.Caption := S ;

これはエラーを生成しますか？警告？VCLがUnicodeになっていると思いますか、それともXEが非Unicodeコンポーネントをプルするのでしょうか、それとも文字列を変換するのでしょうか？XEで8ビット文字列を使用してアプリを維持することは実際に実行可能ですか、それとも頭痛の種が多すぎますか？

Unicodeを使用するのが最善/最も簡単な方法である場合は、少なくとも近い将来、拡張文字を使用しない場合でも、それを実行します。

私が疑問に思うもう一つのことは、サードパーティのものです。XE互換のアップデートバージョンを入手する必要があると思います。

（肯定的な！）コメントをいただければ幸いです。

4

2 に答える 2

1

2006年から2011年にかけての走り幅跳びです

しかし、次のことを考慮すれば可能です。

  • 新しい変換メソッドを使用して文字列変数を変換する必要があります;
  • 2006年からxeまでのすべてのバージョンをチェックして、ライブラリがどのように変更されたかを知る必要があります。これは、一部が分割され、他がマージされ、一部が削除されたためです。
  • サードパーティコンポーネントのアップグレード（ある場合）を購入/ダウンロードする必要があります。
于 2012-06-30T00:41:47.623 に答える
0

AnsiStringVCLは完全にUnicodeになっているため、表示したコードは、からへの暗黙の変換について、エラーではなくコンパイラ警告を生成しますUnicodeString。AnsiStringに非ASCII文字（コンパイラが検証できない）が含まれている場合、これは潜在的に損失の多い変換です。を引き続き使用する場合はAnsiString、警告を回避するために明示的な型キャストを実行する必要があります。

var
  S : AnsiString ; 
...
MainForm.Caption := String(S);

このようにコードをAnsi-fyingしないのが最善です。Unicodeを採用します。コードの管理が容易になり、将来のバージョンやプラットフォームへの移植性が向上します。ネットワーク通信、レガシーデータのファイルI / Oなど、Ansiが実際に必要な場所だけに使用を制限するAnsiString必要があります。アプリ内のメモリを節約したい場合、特にASCII文字のみを使用している場合は、UTF8Stringの代わりにを使用してAnsiStringください。UTF-8はUnicodeの8ビットエンコーディングであり、との間の変換UTF8StringはUnicodeString損失がなく、コンパイラの警告はありません。

于 2012-05-22T17:34:55.757 に答える