6

約2年前、iso-8859-1を使用して大規模なWebサイトを開始するのを間違えました。特にajaxを使用してサーバーにデータを送信するときに、一部の文字で問題が発生しています。このため、UTF-8の使用に切り替えたいと思います。

これからどのような問題が発生すると思いますか？から変更する必要のある文字を探すためにサイトを検索する必要があることを私は知っていますか？彼らの本当のキャラクターに。しかし、これを行うことには他にリスクがありますか？誰かがこれを以前にやったことがありますか？

4

2 に答える 2

7

主な問題は、すべてのデータパスがUTF-8でクリーンであることを確認することです。

  1. あなたのサイトはDBに支えられていますか？その場合は、すべてのテーブルをUTF-8またはその他のUnicodeエンコーディングに変換する必要があるため、並べ替えとテキスト検索は正しく機能します。

  2. あなたのサイトは動的コンテンツにプログラミング言語を使用していますか？（PHP、mod_perl、ASP ...？）その場合、使用している特定の言語インタープリターが何らかの形式のUnicodeを完全に理解していることを確認する必要があります。UTF-8をネイティブに使用していない場合は、変換を実行してください。 — UTF-16が次に最も一般的です—そして、Webサーバーへの出力でUTF-8を使用するように構成されていることを確認してください。

  3. あなたのサイトにはある種のバックエンドアプリサーバーがありますか？テキスト出力にUTF-8を使用していますか？

  4. Webドキュメントの文字セットを宣言できる場所は少なくとも3つあります。必ずすべて変更してください。

    • HTTPContent-Typeヘッダー
    • <meta http-equiv="Content-Type">ドキュメント内のタグ」<head>
    • <?xml>XHTML Strictを使用している場合は、ドキュメントの上部にあるタグ

これはすべて、数年前に、適度に複雑なN層アプリを介してUnicodeデータをトレースし、次のような変換チェーンを見つけたときの経験に基づいています。

Latin-1 → UTF-8 → Latin-1 → UTF-8

そのため、データが「UTF-8」であると主張するブラウザに表示されたとしても、アプリはLatin-1と共通のサブセットしか処理できませんでした。

これらの奇妙な変換チェーンの最大の理由は、当時のツールでのUnicodeサポートが未成熟だったためですが、パイプラインUTF-8をクリーンにするように注意しないと、このような醜さをいじることができます。

Latin-1文字を検索し、ファイルを1つずつ変換することについてのコメントについては、私はそうしません。最新のすべてのLinuxシステムにあるユーティリティを中心にスクリプトを作成し、iconvシステム内のすべてのテキストファイルをフィードして、Latin-1からUTF-8に明示的に変換します。石を回転させないでください。

于 2009-10-20T22:36:36.050 に答える
2

このような変更は、システムのすべての部分に（ほぼ）影響します。データベースからPHP、HTML、Webブラウザーに至るまで、すべてを調べる必要があります。

テストサイトを開始し、いくつかの深刻なテストを行います（さまざまなプラットフォーム上のさまざまなブラウザーがさまざまなことを実行します）。

IMO UTF-8と、それがソフトウェアにとって何を意味するのかを実際に理解することが重要です。いくつかの簡単なポイント：

  • PHPは主にバイト指向です。文字とコードポイントとバイトの違い、およびUTF-8とUnicodeの違いを学びます。
  • UTF-8は適切に設計されています。たとえば、2つのUTF-8文字列が与えられた場合strstr()でも、バイト指向は正しく機能します。
  • 最も一般的な問題は、UTF-8文字列をISO-8859-1として扱い、その逆も同様です。この種のエラーの可能性を低くするために、関数にどのような種類のエンコーディングが期待されるかを示すドキュメントを追加する必要がある場合があります。文字列の可変命名規則（文字列が使用するエンコーディングを示すため）も役立つ場合があります。
于 2009-10-20T22:39:46.713 に答える