私が管理しているアプリケーションは、「latin1」文字セットを使用して、Web ログから抽出されたユーザー エージェントを MySQL テーブル列にロードします。時折、次のようなユーザー エージェントの読み込みに失敗します。
Mozilla/5.0 (Iâ?; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML^C like Gecko) Version
窒息している疑いがありIâ?ます。これをサポートする必要があるのか、それともアップストリームのログ システムによって引き起こされた破損なのかを調査中です。これは HTTP ヘッダーの正当なユーザー エージェントですか?
RFC 2616 (HTTP 1.1)では、メッセージ ヘッダーの内容は「トークン、セパレータ、引用文字列のいずれかまたは組み合わせで構成される」*TEXT必要があると規定されています。TEXT などの定義を見ると、有効な文字は [0, 31] の範囲になく、127 に等しくないバイト値を持つ文字であることがわかります。したがって、 などの文字âは、仕様に従って合法であると言える限りです。
技術的には、127 を超えるオクテットはコメントで許可されます。RFC 2616 ではデフォルトで ISO-8859-1 が使用されていますが、HTTPbis (RFC 2616 の次の改訂版) ではその規則が削除されているため、遠い将来、適切なエンコーディングに移行できる場合があります。
推奨: 127 を超えるすべてのオクテットを取り除きます。
HTTP 1.1 RFC2616は、ラテン語ベースの1バイト文字セットであるISO-8859-1を参照しています。
HTTPトラフィックは1バイトであると想定されていることを考慮して、同様のログにlatin1文字セットも使用しています。決定は単に私のインデックスを小さくすることでした。
VARCHARでUTF8を使用する場合、マルチバイトの文字のみが追加のバイトを必要とするため、表スペースではそれほど余分ではありません。ただし、インデックスは固定幅で格納されるため、必要な場合に備えてスペースが埋め込まれます（UTF8インデックスはlatin1インデックスの3倍の大きさです）。
たまに奇数のヘッダーが読めなくても影響はありません。ただし、列のインデックスを作成していない場合は、UTF8を使用することもできます。