2

実際のシンボル (単に入力できるもの) の代わりに HTML シンボル エンティティを使用する必要がある特別な理由はありますか? たとえば、記号/; その HTML エンティティ コードは です&#47。

HTML コードでシンボルのコードまたはシンボル自体を使用する必要がありますか? また、その理由は?

4

3 に答える 3

1

HTML エンティティ参照を使用すると、ドキュメントに適用されるエンコーディングに関係なく、意図したとおりにエンティティを表すことができます。それがメリットです。

US-ASCII 以外のすべての文字に対してエンティティを厳密に使用するのではなく、ドキュメントのターゲット言語をサポートするドキュメントのエンコーディングを自由に使用してください。できれば、UTF-8 などの他の言語もサポートするエンコーディングを使用してください。

ただし、システム固有のエンコーディング、特に通常の Windows エンコーディングは使用しないでください。Windows-1252 テキストが ISO-8859-1 の間違ったラベルで他のシステムに送信されることがよくあります。

過去には、名前付き HTML エンティティよりも数値 HTML エンティティのサポートの信頼性が低かったことは確かです (私自身の目撃者の観察に基づく)。数値は、UCS ( http://en.wikipedia.org/wiki/Universal_Character_Set ) に登録されたコード ポイントを直接参照し、その定義された文字名に相当します。

警告：以下は私自身の経験を説明しており、あなたの経験は異なる場合があります.

  • シンボルを直接埋め込んで作業するためにクライアントから転送された HTML ドキュメントは、非常に頻繁に破損しており、復元できません。これは、米国のインフラストラクチャの弱点か、ドキュメントの送信方法に関する顧客側の知識不足である可能性があります。主要言語が非 ASCII 文字に依存している国のインフラストラクチャと人々は、破損することなくドキュメントを適切に転送する方法をサポートし、理解する可能性がはるかに高くなります。

  • 独自の Web サイトを開発し、独自のファイルの最終コピーをサーバーにアップロードしている場合、破損のリスクは非常に小さくなります。

  • ドキュメントを編集した時点からユーザーに提供する時点までドキュメントを制御できない場合は、リスクを冒すことになります (おそらく今日ではありませんが、米国ではここ数年で確実に、単なるリスク以上の可能性が生じます)。 ) 途中のある時点で文書が不適切に変換され、どのエンコーディングで表示しようとしても永久に破損する可能性があります。

于 2013-05-16T20:19:18.370 に答える
0

いいえ。

エンティティと文字参照は、次の場合にのみ役立ちます。

  • その文字は、その文字を使用したい場所で HTML 内で特別な意味を持ちます (絶対に使用しません。いずれにせよ、as データ/を使用できない場所でのみ特別な意味を持ちます)。/
  • 文字を入力できません (たとえば、キーボードに表示されないため)。
  • ファイルを UTF-8 としてエンコードすることはできません (またはそれを含む別のエンコードで… /ASCII で表示されます)。
于 2013-05-16T18:19:50.923 に答える
-3

HTML を編集するために常に同じソフトウェアとコンピューター システムを使用するという事実を認識していない限り、シンボルを直接使用すると、指定した文字エンコーディングに関係なく、独自のコードを編集できない状況に必然的に遭遇します。ドキュメントまたは HTTP ヘッダーを使用します。文字エンコーディングが常に適切に転送されるのは完璧な世界だけです。

利用可能なすべてのエンコーディング システムを真にサポートするソフトウェアで、Macintosh または Windows から「適切に」エンコードされているはずのドキュメントを開くと、次のようなメッセージが表示されます。

-=-J(DOS)**--F1   Top L3     (Text) ----------------------------------------
These default coding systems were tried to encode text
in the buffer:
  (iso-2022-7bit-dos (284 . 4194194) (379 . 4194194) (462 . 4194195)
  (492 . 4194196) (635 . 4194195) (640 . 4194196) (642 . 4194195) (772
  . 4194196) (833 . 4194195) (839 . 4194196) (857 . 4194195))
  (utf-8-dos (284 . 4194194) (379 . 4194194) (462 . 4194195) (492
  . 4194196) (635 . 4194195) (640 . 4194196) (642 . 4194195) (772
  . 4194196) (833 . 4194195) (839 . 4194196) (857 . 4194195))
However, each of them encountered characters it couldn't encode:
  iso-2022-7bit-dos cannot encode these: \222 \222 \223 \224 \223 \224 \223 \224 \223 \224 ...
  utf-8-dos cannot encode these: \222 \222 \223 \224 \223 \224 \223 \224 \223 \224 ...

Click on a character (or switch to this window by `C-x o'
and select the characters by RET) to jump to the place it appears,
where `C-u C-x =' will give information about it.

Select one of the safe coding systems listed below,
or cancel the writing with C-g and edit the buffer
   to remove or modify the problematic characters,
or specify any other coding system (and risk losing
   the problematic characters).

  thai-tis620

データがサーバーから取り出されるとすぐに、たとえば電子メールなどに配置されると、エンコーディングが渡される保証はなく、そうでない可能性があることに注意してください。ドキュメントを識別するためのバイト マークやその他の目に見えない手段は、約束どおりには機能しません。ましてや、HTTP ヘッダーなどの一時的なメソッドは、ドキュメントが慎重に構成された独自の HTTP サーバーのコンテキストを超えて移動するとすぐに失われます。

HTML の指針となる原則は、適切に使用された場合、最も基本的なテキストをサポートするあらゆるシステムと普遍的に互換性のあるプレーン テキスト マークアップ言語であるということです。HTML ドキュメントでは、通常の 7 ビット US-ASCII 文字セット以外の文字には HTML エンティティを使用する必要があります。その他の文字は、使用されるエンコーディングに応じて異なるバイナリ定義を持ち、シングルバイト表現とマルチバイト表現の間で異なる場合さえあります。

HTML 以外のドキュメント内では、未加工のシンボルを自由に使用できます。これは、ネイティブ ファイル形式または HTML 内にそれらを埋め込むときに、「正しい」文字エンコーディング、つまり、作成したシステムと、それと互換性のあるシステム。

于 2013-05-16T18:37:37.043 に答える