この入力テキストには、多くの場合、Windows-1252 エンコーディングのドキュメントに由来する「スマート クォート」など、出力エンコーディングには不適切な文字が含まれています。
「スマート クォート」 (cp1252 のバイト 147 と 148) は、完全に有効な Unicode 文字、U+201C と U+201D です。アプリケーションはそれらをシームレスに処理できる必要があります。そうでない場合は、何か間違ったことをしており、おそらくすべての非 ASCII 文字が失敗します。
文字が入力されたものか、Word から貼り付けられたものかに関係なく、ブラウザは UTF-8 でエンコードされた文字をアプリケーションに送信する必要があり、アプリケーションは同じ UTF-8 バイトをデータベースに保存する必要があります。
ブラウザーが UTF-8 で送信しない場合、フォームを含む HTML ページの文字セットを設定していない可能性があります。これは、次を使用して実行できます。
Content-Type: text/html;charset=utf-8
HTTP ヘッダーおよび/または:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<head> 内の要素。
フォームに accept-charset 属性を設定するだけで、ブラウザにそれを実行させることはできますか?
いいえ、accept-charset は IE のおかげで基本的に役に立ちません。IE は、「常にこの文字セットを使用する」のではなく、「ページ上の文字セットが必要な文字をエンコードできない場合は、この文字セットを使用してみてください」と誤解します。これは、accept-charset を使用すると、一度に送信されたエンコーディングが混在することになり、どれがどれであるかを判断する方法がないことを意味します。良い！
データベースが UTF-8 の予約/制御文字であるこれらの文字を受け入れるのはなぜですか?
MySQL では、UTF-8 は単なる照合であり、比較と順序付けに使用されます。データはまだバイトとして保存されており、有効な UTF-8 シーケンスでないかどうかは気にしません。
いずれにせよ、受信した UTF-8 シーケンスをアプリでデコードしてチェックすることをお勧めします。これは、最新の Unicode では無効な「短いシーケンス」が「<」を隠す可能性があるためです。古いブラウザ (少なくとも SP2 より前の IE6、Opera 7) でも認識される文字。
到着予定時刻:
というわけで、バイト146を含む文字列を入力しました
いいえ、Unicode 文字 U+201B を入力しました。ブラウザーは、シリアル化されたフォームをサーバーに送信する必要がある時点まで、バイトではなく Unicode 文字を処理します。次に、文字をバイトに変換する方法を決定し、ページが UTF-8 として処理されている場合は、常に UTF-8 を選択します。
(UTF-8 でない場合、ブラウザは標準に準拠しない方法でごまかす傾向があります。エンコーディングに収まらないすべての文字については、「’」のような HTML 文字参照にエンコードします。ブラウザがエスケープした '&' と実際のユーザーが入力した '&' の違いがわからないため、これは間違っています。また、参照をエスケープされていない HTML としてエコーすると、正しく理解しているかのように、実際には大きな古いセキュリティ ホールを作成しただけです。)
146としてデータベースに入りました
本当に、'\xC2\x92'、'\xE2\x80\x99'、'' ではなく、'\x92' バイトですか?
(UTF-8 でエンコードされた) XML を 146 として作成したときに出てきました。ブラウザーからの苦情はありません。
その後、単一の 146 バイトとして出力されませんでした。XML ファイルでそのままの '\x92' を指定すると、ブラウザーはエラーを出します。(無効な UTF-8 シーケンスが欠落文字グリフとして表示される HTML ファイルではありません。)
「’」として出てくるのではないかと思います。整形式の文字参照 (ただし、文字 U+0092 は C1 コントロール セットの一部であるため、有用なものとしてレンダリングされません)。これが起こっている場合、フォーム ページは結局 UTF-8 として認識されず、上記のブラウザの自動エスケープ送信の問題に苦しんでいます。