XHTMLとXMLのアクセント記号と特殊文字のエンコードについてはどう思いますか？UTF8、ISO-8859-x、または7ビットのASCIIおよびエンティティ
なぜかを詳しく教えてください。
なぜ私はこのことが起こったのか正確には言えませんが、5年ごとにすべてのウェブページ（私は主にキリル文字とバルト記号を使用しています）でUTF-8を使用した経験では、 。
名前付きエンティティを気にしないでください。これらは、HTMLファイルを手動で編集し、その文字を読み取る必要があり、UTF-8エディターを使用しない場合に適しています。しかし、そうでなければ、UTF-8が道のりです。
アメリカの視点から言うと、ほぼすべてのテキストがUS-ASCIIで、記号やアクセント付きの文字がいくつかあるため、数値または名前付きエンティティを使用することを強くお勧めします。
理由は簡単です：心配することは1つ少ないです。ウェブサーバーがコンテンツと同じエンコードを宣伝するように設定されている必要はありません。遅かれ早かれ、Cp1252エンコーディングを使用してWindows上でページを編集したり、Linux上でISO-8859で作業している他の人がいるかもしれません。また、WebサーバーがUTF-8として設定されている場合、両方が壊れています。
これは、主にASCII以外のテキストを使って作業している場合、大量のエンティティを必要としないため、私はSergej +1を付けました。
+1それには何かがあります。私はデフォルトではすべてのUTF-8をLinuxに持っていますが、webdesignersはISO-8859-1のすべてをエンコードします。しかし、エディタの「自動検出エンコード」オプションは便利です:-) – vartec
これは、静的なWebページを構築していて、関係するすべての人と直接接触している場合にのみ有効です。それでも、エンティティに変換しない人には対処する必要があります。これは、UTF8でファイルを保存する方法について説明するのと同じくらい重大な問題です。 通常のWebアプリケーションの場合、このような態度は危険です。なぜなら、エンコーディングに気づいていないチェーンにリンクが残ってしまい、すべてのユーザーデータが永久に破損してしまうからです。エンティティを使用するかどうかにかかわらず、エンコードを直接取得する必要があります。または、あなたは傷ついている世界のためです。 – gtd
開発チームの仕事の一部はコミュニケーションです。しかし、通常はチーム内でコミュニケーションをとる方が簡単です。多くの企業では、展開は開発とは別に管理されます。 Web-appスタックを使ってエンコードを管理する場合：あなたのプラットフォームがこれをやっていない場合、あなたは傷ついている世界です。しかし、ねえ、遅いdownvoteのおかげで。 – kdgregory
私はいつもutf8を直接書きます。私がこの期間中に抱いていた唯一の問題は、ヘッダーにisoエンコーディングを強制していたサーバーでした。
UTF-8。
これはUTF-16で発生するkdgregoryの問題を解決する目的で設計されており、それは驚くほどです。今日のほとんどのエディタ（メモ帳を含む）は、UTF-8をサポートしており、XMLのデフォルトエンコーディングでもあります。
常に最新のフレームワークやデータベースサーバでUTF-8をサポートするには異議/問題はありませんあなたのサイト
ためUTF-8を使用します。
誰かが予想外の言語でテキストを入力して、??????いくつかのユニコード記号の代わりに、さらにはページテンプレートがレンダリングされていないときさえ悪化します。
あなたのサイトでも、多言語インターフェースなしで（ある特定の言語に）タグ付けされていても、あなたのサイトの資料を公開し、自分の言語で友人からコメントを得ることができます。
よろしく、 パベル
私は個人的には常にUTF-8を使用します。それはうまくサポートされており、すべての言語、OS、およびブラウザが何とかサポートしています。エンティティは表示するのが楽しいですが、編集する首の痛みです。名前付きエンティティは多くの文字を参照できますが、オシデンタール文字セットのみをカバーします。アジア言語の場合は、16進数のエンティティに戻らなければなりません。とにかにUnicodeテーブルを使用して16進エンティティをデコードまたはエンコードする必要があるため、最初にUnicodeフレーバーを使用してテキストをエンコードすることもできます。
あなたの主な視聴者が英語の場合、あなたはISO-8859-1またはcp1252で逃げることができますが、それは間違いでしょう。遅かれ早かれ誰かがアクセント付きの文字やその他の外国の文字を書くつもりで、そのようなことが起きると、エンコーディングを修正するのが遅すぎます。ここで
は、文字セットで遊んでたときに私に頭痛の多くを保存している、さらに読書の集まりです：
Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)はjoelonsoftware.comによる文字セットとその使用法との違いに詳細な紹介です。その情報は非常に一般的ですが、どのエンコーディングを選択するかを理解するのに役立ちます。
Character sets from Browser to Databaseは、エンコードが他のものに変換されていないことを確認する必要がある様々な場所について、たくさんのことをカバーするSUNの非常に実用的で実用的な記事です。
What Is UTF-8 And Why Is It Important?はSUNの別の記事で、UTF-8の根深い部分に入り込み、最初の2つの記事を読んだ後にUTF-8の詳細について質問に答えてください。
主にASCIIスペース（英語、ほとんどのロマンス言語）のWebサイトで作業している場合、非ASCIIのすべてを名前付きエンティティまたは番号付きエンティティに変換します。これにより、私や他の人が適切なフォントを使用しないで作業できるようになります。たとえあると思われるかもしれませんが、ある日、UTF-8を使用しないSSH上の端末を使用してしまいます。ホストシステムに正しいフォントがインストールされていなくても、終わりです。
ほとんどASCIIでないテキストを書いている場合は、UTF-8を使用します。テキストが、Unicodeの置換ボックスと同じように読めないすべてのエンティティである場合。
Unicodeの最初の128文字は、ASCIIと互換性があります。これらの128文字で書かれたテキストは、有効なASCIIとUTF-8の両方のドキュメントです。 Unicodeは標準であり、誰でも使用する必要があります。英語の話者は違いは見えませんが、英語以外の人は違いが見えます。個人的には、ソフトウェアとそのクリエイターには、私の姓さえ正しく保存して表示することができない場合、私はかなり失望しています。
また、文字エンコーディングは内部化に関する一連の問題の最初のものに過ぎないことにも気付かなければなりません。特に、非英語の文法上の問題を扱うように設計されていない小規模のソフトウェアでは、特に注意が必要です。
もちろん、7ビットASCIIはUTF-8のベースです。しかしそれは英語のみのテキストでさえ助けにならない。あなたは©、¢、½を持っています... – vartec
私はこの音を試験問題のようにするのが大好きです... NOT – hop