CHARSET

CHARSETはtelnetオプション42で、RFC 2066で規定されています。一方が文字セットの一覧を提示し、もう一方が そこから1つを選び、両者はバイトと文字の対応について合意します。

実際には、このネゴシエーションはUTF-8に落ち着くか、そもそも行われないかのどちらかです。MUSHの系統は MUDの系統よりもはっきり多くネゴシエートしており — TinyMUX、RhostMUSH、PennMUSHはいずれも行います — これは名前の入った文章を書く人たちの集まりであることの表れです。

これがないと何が起きるか

クライアントは推測するしかなく、たいていの推測はASCIIかLatin-1です。ASCIIと推測すれば0x7Fを超える バイトはすべて疑問符になり、UTF-8のサーバーをLatin-1と推測すればアクセント付きの文字はどれも2つの 記号に化けます。どちらの失敗もゲームのせいに見えますが、そうではありません。

クローラーにとっては、これが特定の場所で効いてきます。当サイトが使っているtelnetライブラリは、現在の エンコーディングの既定値をASCIIにしており、この既定値は無害ではありません — CHARSETを一度も ネゴシエートしないサーバー、つまり大半のサーバーでは、すべてのバイトがこれで復号されます。だからこそ 当サイトは意図してその初期値を与えています。

CHARSETが届かない唯一の場所

MSSPのフィールド名と値は、CHARSETが何に落ち着いたかに関係なくASCIIとして復号されます。 サブネゴシエーションはテキストではなくコマンドであり、仕様がCHARSETの適用範囲をテキストに限って いるからです。これは仕様に適合していると言えなくもありませんが、情報は失われます。MSSPのNAMEが Café NoirのゲームはCaf? Noirと報告し、元のバイトは当サイトが手を出せるどの段階よりも前に 消えています。

当サイトの自己申告のフィールドで文字化けが見えるのに、ゲーム自身の出力では見えない場合、理由はこれで あり、当サイトの側からは復元できません。