同じ赤文字がJavaとBedrockで壊れる理由
あるプラグインでは完璧に表示されるカラーコードが、別のプラグインではそのままアンパサンドとして表示される。原因はプラグインではなくフォーマットにある。
§ コードと MiniMessage タグは同じ色を表現していても、同じサーバーに拒否されることがある。サーバーの色付きテキストは単一のフォーマットではない——少なくとも5種類あり、プラグインごとにどれを受け付けるかが異なる。
5つの方言
| 方言 | 見た目 | 生き残る場所 |
|---|---|---|
| レガシーセクション | §cHello | バニラチャット、古いプラグイン |
| アンパサンドレガシー | &cHello | コンフィグファイル、多くのプラグイン |
| BungeeCord hex | &x&f&f&0&0&0&0 | プロキシプラグイン、一部のチャット |
| MiniMessage | <red>Hello</red> | モダンなPaperプラグイン |
| JSONコンポーネント | {"text":"Hello","color":"red"} | バニラコマンド、/tellraw |
アンパサンド形式は、何かが変換してくれるまではカラーコードですらない。MiniMessageを期待するプラグインに &c を貼り付ければ、プレイヤーにはそのままの文字が表示される。
レガシーコードは色が足りない
セクション記号のシステムには、固定された色文字とフォーマット切替しかない。任意の色を表現する方法は存在しない。hexは後から登場し、BungeeCord形式では1文字ずつエンコードする——&x の後に & 接頭辞付きのhex数字6桁が続くため、あんなに長く見えるのだ。
MiniMessageは #ff0000 を直接受け取る。JSONは同じhexを文字列値として受け取る。
JavaとBedrockは一致しない
Bedrockもセクション記号を使うが、その色セットとフォーマットリセットの扱いはJavaとは異なる。Javaサーバーで正しく表示される文字列が、Bedrockクライアントでは余計な文字として表示されることがあり、クロスプレイプロキシはテキストをそのまま通すのではなく両者間で変換することが多い。サーバーがBedrockプレイヤーを受け入れるなら、両方で出力をテストしよう。
ネストの罠
レガシーコードは状態を持つ。色コードはフォーマットをリセットするので、§l§cBold は赤かつ太字だが、§c§lBold は次の色コードまで太字の赤で、その色コードが太字を消す。MiniMessageはツリー構造であり、<red><bold>text</bold></red> はきれいに閉じる。ネストされたMiniMessage文字列をレガシーコードに変換すると構造が失われる。レガシーには閉じタグが存在しないからだ。
エスケープ
MiniMessageは < を構文として扱う。<Steve> という名前のプレイヤーは、その名前をコンポーネントとしてパースするあらゆるプラグインを壊す。レガシーフォーマットも & で同じ問題を抱えており、だからこそ多くのプラグインは && かエスケープ用のコンフィグフラグを要求する。
テキストは一度書いて、プラグインが実際にパースする方言を選び、Server Text Studio から正確な文字列をコピーしよう。