CHARSET  [プロトコル]
エンコーディングを取り決めるための、RFC
2066のtelnetオプション。ゲームのアクセント付きの名前が無事に届く理由であり、これがないときに起きる分かりにくい失敗の原因でもあります。
https://www.rfc-editor.org/rfc/rfc2066

実測した採用状況
  掲載886件のゲームのうち114件で提供を観測（12.9%）
  /ja/games?protocol=CHARSET

  ここに数えていないゲームは、そのプロトコルを持たないゲームということではない。数えるのは、そのサーバーがハンドシェイクでそのオプションを提供するのを観測したとき。残りは、当サイトに提供しなかったサーバーと、ハンドシェイクをまだ読んでいないサーバーであり、どちらなのかは言えない。

  特定できたゲームの、コードベース別
    PennMUSH             34件のうち28件が提供
    FluffOS              28件のうち16件が提供
    RhostMUSH            40件のうち5件が提供
    ROM                  55件のうち2件が提供
    SMAUG                20件のうち1件が提供
    AresMUSH             18件のうち0件が提供
    CircleMUD            47件のうち0件が提供
    CobraMUSH            2件のうち0件が提供
    CoffeeMUD            32件のうち0件が提供
    DikuMUD              35件のうち0件が提供
    Evennia              11件のうち0件が提供
    MUCK                 24件のうち0件が提供
    tbaMUD               5件のうち0件が提供
    TinyMUSH             9件のうち0件が提供

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と報告し、元のバイトは当サイトが手を出せるどの段階よりも前に 消えています。

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

関連項目
  TTYPEとMTTS — /ja/reference/protocols/ttype
  接続のしかた — /ja/reference/connecting
  TinyMUX — /ja/reference/codebases/tinymux