12

ほぼ5年前、Joel Spolskyはこの記事を書いています、「絶対に最小限のすべてのソフトウェア開発者は絶対に、積極的にUnicodeと文字セットについて知っている必要があります（言い訳はありません！）」。

多くの人と同じように、私はそれを注意深く読み、この「ASCIIの置き換え」を理解するのは時期尚早であることに気づきました。残念ながら、5年後、私はこの地域のいくつかの悪い習慣に戻ったと感じています。ありますか？

私は特に国際的なアプリケーションをあまり作成していませんが、ASP.NETインターネット向けのWebサイトの構築を支援してきたので、それは言い訳にはならないと思います。

ですから、私の利益のために（そして私は他の多くの人を信じています）、次のような人々からいくつかの意見を得ることができますか？

  • ASCIIを「乗り越える」方法
  • Unicodeを使用する際の基本的なガイダンス。
  • Unicodeに関する推奨（最近の）書籍およびWebサイト（開発者向け）。
  • Unicodeの現在の状態（Joelsの記事から5年後）
  • 今後の方向性。

私は.NETのバックグラウンドを持っていることを認めなければならないので、.NETFrameworkのUnicodeに関する情報も喜んでいます。もちろん、これは、異なる背景を持つ人がコメントするのを止めるべきではありません。

更新：以前にStackOverflowで尋ねられたこの関連する質問を参照してください。

4

4 に答える 4

9

Joelの記事と他のいくつかのI18nの記事を読んだので、私は常に文字エンコードに注意を払いました。そして、あなたがそれを一貫して行うならば、それは実際に機能します。UTF-8を使用することが標準である会社で働いていて、誰もがこれを知っている/これを行う場合、それは機能します。

ここに、この主題に関するいくつかの興味深い記事（ジョエルの記事以外）があります：

最初の記事からの引用。Unicodeを使用するためのヒント：

  • Unicodeを採用し、それと戦わないでください。それはおそらく正しいことであり、そうでなかったとしても、とにかくそうしなければならないでしょう。
  • ソフトウェア内に、テキストをUTF-8またはUTF-16として保存します。つまり、2つのうちの1つを選び、それを使い続けます。
  • 可能な限りXMLを使用してデータを外部と交換します。これにより、多くの潜在的な問題が解消されます。
  • 独自のクライアントを作成するのではなく、アプリケーションをブラウザベースにするようにしてください。ブラウザは、世界のテキストを処理するのに非常に優れています。
  • 他の人のライブラリコードを使用している場合（そしてもちろんあなたもそうです）、正しいことが証明されるまでそのUnicode処理が壊れていると想定してください。
  • 検索を行う場合は、言語および文字処理の問題を理解している人に渡してみてください。
  • アマゾンかどこかに行って、印刷されたUnicode標準の最新リビジョンを購入してください。それはあなたが知る必要があるすべてをかなりよく含んでいます。
  • Unicode Webサイトをざっと見て、コードチャートがどのように機能するかを学びましょう。
  • アジアの言語で真剣な仕事をしなければならない場合は、ケン・ランディの主題に関するオライリーの本を購入してください。
  • Macintoshを使用している場合は、LordPixelのUnicodeフォント検査ツールを使い果たして入手してください。完全にクール。
  • 本当にデータに取り憑かれなければならない場合は、年に2回開催されるUnicodeカンファレンスの1つに参加してください。すべての専門家が行き、あなたが知る必要があることを知らなければ、あなたはそこで知っている誰かを見つけることができるでしょう。
于 2008-09-12T14:38:56.557 に答える
4

私は検索エンジンソフトウェアでしばらく作業していました-ページのエンコーディングについて嘘をついているHTTPヘッダーまたはメタタグを備えたコンテンツを提供するWebサイトがいくつあるか信じられないでしょう。多くの場合、ISO-8859文字とUTF-8文字の両方を含むドキュメントを入手することもあります。

これらの種類の問題のいくつかを乗り越えたら、生成するデータの適切な文字エンコードを真剣に受け止め始めます。

于 2008-09-12T14:26:19.567 に答える
3

.NET Framework は、文字列の格納に Windows の既定のエンコードを使用しますが、これは UTF-16 であることが判明しています。ほとんどのテキスト I/O クラスを使用するときにエンコーディングを指定しない場合、BOM なしで UTF-8 を記述し、最初に BOM をチェックしてから UTF-8 を想定して読み取ることになります (私は確かに知ってStreamReaderおり、StreamWriterこのように動作します。 ) これは、BOM を理解しない「愚かな」テキスト エディターにとってはかなり安全ですが、UTF-8 を表示できるスマートなテキスト エディターや、標準の ASCII 範囲外の文字を実際に書いている状況では、ちょっと厄介です。

通常、これは目に見えませんが、興味深い方法で頭をもたげることができます。昨日、XML シリアライゼーションを使用して を使用してオブジェクトを文字列にシリアライズしていた人と仕事をしていましたがStringWriter、エンコーディングが常に UTF-16 である理由を彼は理解できませんでした。メモリ内の文字列は UTF-16 になり、それが .NET によって強制されるため、XML シリアライゼーション フレームワークが実行できる唯一のことです。

なので、ただの使い捨てツールではないものを書くときは、BOM で UTF-8 エンコーディングを指定します。技術的には、.NET では常に誤って Unicode を認識しますが、それはユーザーがエンコーディングを UTF-8 として検出することを知っている場合のみです。

誰かが「文字列のバイトを取得するにはどうすればよいですか?」と尋ねるのを見るたびに、少し泣きそうになります。提案された解決策はEncoding.ASCII.GetBytes():(を使用します

于 2008-09-12T15:08:56.237 に答える
2

経験則: 文字列を変更したり内部を調べたりせず、代わりに厳密にデータの塊として扱うと、はるかにうまくいくでしょう。

単語を分割したり、文字列を小文字にしたりするような単純なことでも、「Unicode の方法」で実行したい場合は難しくなります。

そして、それを「Unicode の方法で」実行したい場合は、非常に優れたライブラリが必要になります。これは信じられないほど複雑です。

于 2008-09-12T14:54:41.620 に答える