問題タブ [internationalization]

2 つの場所で使用されるクライアント用のアプリを維持しています。イングランドに1つ、ポーランドに1つ。

データベースはイギリスに保存され、通貨に £1000.00 の形式を使用していますが、情報はポーランドでローカルに収集されており、1000,00 が形式です。

私の質問は、VB6 に、通貨文字列をローカル形式で取り、別の形式に変換する関数があるか、または文字列を解析して , または を置き換えるだけでよいかということです。?

ところで、私はCCurを見てきましたが、それが私が望むことをするかどうかはわかりません.

データベースに国際住所を保存するための「最良の」方法は何ですか？スキーマの形式で回答し、自分が行った方法を正規化する（またはしない）ことを選択した理由を説明します。また、各フィールドのタイプと長さを選択した理由も説明してください。

注：必要と思われるフィールドはユーザーが決定します。

ここ数年、私は多くの PHP プログラミングを行ってきましたが、私を悩ませ続けていることの 1 つは、Unicode とマルチバイト文字列のサポートが弱いことです (確かに、ネイティブには何もありません)。たとえば、「htmlentities」は PHP の世界でよく使用される関数のようですが、すべての文字列をローカライズ可能に保ち、データベースに UTF-8 のみを保存し、UTF のみを配信するように努力すると、非常に面倒であることがわかりました。 -8 Web ページなど 突然、データベースとブラウザの間のどこかに、すべてのバイトが文字であると偽ってすべてを台無しにする、この絶望的に単純な機能があります。

この種の関数をダンプしたいだけです。それらはまったく不要に思えます。最近でも「ä」と書く必要がありますか? 「あ」の代わりに？少なくとも、私の Firefox は、適切なエンコーディングで提供されている限り、最も奇妙なアジアのグリフでも問題なく表示できるようです。

更新：より正確に言うと、HTMLタグを表示する以外に必要な名前付きエンティティです（「<」の「<」など）

更新 2:

@Konrad: いいえ、名前付きエンティティは必要ないと言っていますか?

@Ross:しかし、出力ロジックをそのような問題から解放するために、入力時にユーザー入力をサニタイズする方が良いのではないでしょうか? （もちろん、入力で信頼できるサニタイズが可能であると仮定します-しかし、そうでない場合、出力で可能ですか？）

私は次の文法を構築しようとしています:

数値: 整数 | フロート | インフィニティ | インフィニティ | PI ... INFINITY: '∞' PI: 'π'

しかし、Antlr は文法のロードを拒否します。

私の Tapestry アプリケーションのログイン ページには、ユーザーが入力したパスワードが格納されるプロパティがあり、データベースの値と比較されます。ユーザーが次のようなマルチバイト文字を含むパスワードを入力した場合:

... getPassword() (対応するプロパティの抽象メソッド) の戻り値を調べると、次のようになります。

明らかに、それは適切にエンコードされていません。それでも Firebug は、ページが UTF-8 で提供されると報告しているため、おそらくフォーム送信要求も UTF-8 でエンコードされるでしょう。データベースからの値を検査すると、正しい文字列が生成されるため、OS または IDE エンコーディングの問題ではないようです。.application ファイルの org.apache.tapestry.output-encoding の Tapestry のデフォルト値をオーバーライドしていません。また、Tapestry 4 のドキュメントには、プロパティのデフォルト値が UTF-8 であることが示されています。

では、Tapestry がプロパティを設定するときにエンコーディングを失敗しているように見えるのはなぜでしょうか?

関連するコードは次のとおりです。

ログイン.html

ログインページ

ログイン.java

アップデート

@Jan Soltis:データベースから取得した値を調べると、正しい文字列が表示されるので、エディター、OS、およびデータベースがすべて値を正しくエンコードしているように見えます。.application ファイルも確認しました。org.apache.tapestry.output-encoding エントリが含まれておらず、Tapestry 4 のドキュメントには、このプロパティのデフォルト値が UTF-8 であることが示されています。あなたの質問への回答を反映するために、上記の説明を更新しました。

@myself: 解決策が見つかりました。

MySQLテーブルをデフォルトのケースに依存しないスウェーデン語またはASCII文字セットからutf-8に移行しようとするときに注意すべきヒントや落とし穴はありますか？私が関わっているプロジェクトのいくつかは、より良い国際化を目指して努力しており、データベースはこの変化の重要な部分になるでしょう。

データベースの変更を検討する前に、すべての入力/出力が同じ文字セットを使用していることを確認するために、UTF-8文字エンコード（重要度の低いものから高いものへ）を使用するように各サイトを変換します。

助けてくれてありがとう

多言語環境で C++/MFC プログラムを作成しています。私は 1 つの主要な (国語) 言語と 3 つの国際言語を持っています。プログラムに機能を追加するたびに、国際言語を国内言語に合わせて最新の状態に保つ必要があります。Visual Studio のリソース エディターは、文字列やダイアログ ボックスなどを未翻訳のままにしておくことがよくあるため、あまり役に立ちません。

リソース (.rc) ファイルを編集して、

• 翻訳する文字列とそれぞれの ID のみを含むファイルを作成し、同じ (または類似の) ファイルを別の言語で受け入れる (通常、翻訳は他の人によって行われるため、これは役に立ちます)。
• 翻訳自体を処理し、同じ文字列を異なる言語で同時に表示できるようにします。

最終的には、.rc ファイルから文字列を抽出して翻訳できるようにしたかっただけですが、.rc ファイルに関連するものはすべて機能します。

私はいくつかの国際化の問題を抱えています：

UTF-8 文字列フィールドがブラウザーで ???? としてレンダリングされています。データベースから返された後。

Hibernate を使用してデータベースから取得した後、Eclipse デバッガーを使用して検査すると、文字列フィールドが正しく表示されます。

ただし、Struts2/Tiles はこれらの文字列を ???? としてレンダリングしています。ブラウザに送信される HTML 内。

charset ディレクティブは HTML ヘッダーにあります。

おそらく、struts2 または tiles 構成に何かを追加する必要がありますか?

しばらく前に、「スクリプト化されたコンテンツでの文字列の再利用」に関する W3C の記事を読んでいました。この記事には、国際化に関する有益なアドバイスが含まれていますが、繰り返しコードを排除するという DRY (Don't Repeat Yourself) 原則と矛盾しているように感じました。 .

彼らの例を挙げると、次のようなコードがあるかもしれません...

私の本能は、次のように繰り返しを大まかに排除することです...

...しかし、スペイン語にローカライズする必要がある場合、コードに問題が生じる可能性があります。これは、これら 2 つのケースでは「on」を表す単語が明らかに異なるためです。

私の質問は、他の開発者はどのように DRY 原則とコードの国際化のバランスを取ることに取り組んできたのでしょうか?

私の一部は、国際化は「<a href="http://www.extremeprogramming.org/rules/early.html" rel="noreferrer">あなたはそれを必要としない」状況の極端なプログラミングの1つであると主張したい. ただし、反対に、DRY 原則を念頭に置いたリファクタリングは、必要に応じて機能を簡単に実装できるようにすることで、このバランスを取ることになっています。