EMダッシュ(—またはHTMLの—
)を含むASCIIファイルを持っています。 16進値は0x97です。このファイルを1つのアプリケーションに渡すと、UTF-8として届き、文字を0xC297に変換します。これは、HTMLでは—
です。ただし、このファイルを別のアプリケーションに渡すと、文字が0xE28094または—
に変換されます。
これらのアプリケーションがこれらの文字を異なる方法で変換する原因は何ですか?おそらくコードページの設定ですか?
—
は全角ダッシュではありません 、あなたのテキストは全角ダッシュからその値に誤って翻訳されました。—
はemダッシュのHTML 10進数エンティティです。具体的には、emダッシュを表すUnicodeコードポイント8212を参照しています。最初のアプリ...
データは、w-1252でエンコードされた全角ダッシュとして開始されました。 w-1252では、emダッシュは10進数の値151(16進数では0x97、2進数では10010111)にマッピングされます。
ある時点で、emダッシュは、ファイル内のバイトがiso-8859-1でエンコードされたテキストであると考えるコードによって処理されました。そのコードが0x97を文字列/文字として解釈したとき x97をiso-8859-1エンコーディングに従って文字にマッピング 。 iso-8859-1では、0x97は「ガードされた領域の終わり」という文字にマップされます。
次に、コードが「保護領域の終わり」の制御文字であると考える文字列は、utf-8としてエンコードされました。 tf-8でエンコードされた「保護領域の終わり」は2バイトのシーケンスです:0xC2 0x97 。
2番目のアプリ...
テキストファイルはw-1252として正しく解釈されたため、0x97はemダッシュとして認識され、utf-8では0xE2 0x80 0x94でemダッシュとして正しくエンコードされました。
この動作に影響するもの
Webアプリケーションを扱っているのか、何を扱っているのかはわかりませんが、コンセプトはどのようなものであっても同じである必要があります。人々がフォームにデータを入力するWebアプリで同じ0x97-> 0xC297シナリオがありました。 Webページの文字セットがiso8859-1として宣言されていることがわかりました。ブラウザがw1252文字を処理する最善の方法は、ユーザーやサーバーに警告せずに、それらをisoバイトとして送信することです。サーバーは、データをisoと見なして受信し、utf-8に変換して、0xC297を生成します。
基本的に、アプリがテキストに触れるときは常に、テキストのエンコード方法を通知する必要があります。そうしないと、システムのデフォルトにフォールバックする可能性があります。その場合、データが破損するおそれがあります。
ASCII文字セットは0x00から0x7Fまでの範囲であるため、ASCIIファイルに文字0x97を含めることはできません。したがって、ファイルはASCIIではなく、シングルバイトエンコーディング。たとえば、windows-1250エンコーディングでは、0x97にem-dashがあります。
アプリケーションが、ファイルの作成に使用されたもの以外のエンコードを使用してテキストファイルをデコードする場合、0x7Fを超える文字はすべて正しくありません。
Unicodeでは、em-dashの文字コードは0x2014、つまり10進数では8212です。
たとえば、Windows-1250をエンコードとして使用するWebページでは、コード—
はem-dashとしてレンダリングされます:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>em-dash</title>
<meta http-equiv="content-type" content="text/html; charset=windows-1250"/>
</head>
<body>
<div>—</div>
</body>
</html>