同样的红色文本在 Java 和 Bedrock 上却会出错
一个颜色代码在某个插件里显示完美，换到下一个插件却变成了字面的 & 符号。问题出在格式，而不是插件。
§ 代码和 MiniMessage 标签可以描述同一种颜色，却仍然会被同一台服务器拒绝。服务器彩色文本并不是一种格式——它至少有五种，而各个插件对接受哪种格式各执一词。
五种方言
| 方言 | 外观 | 适用范围 |
|---|---|---|
| 传统分节符 | §cHello | 原版聊天、较旧的插件 |
| & 号传统格式 | &cHello | 配置文件、许多插件 |
| BungeeCord 十六进制 | &x&f&f&0&0&0&0 | 代理插件、部分聊天 |
| MiniMessage | <red>Hello</red> | 现代 Paper 插件 |
| JSON 组件 | {"text":"Hello","color":"red"} | 原版命令、/tellraw |
& 号形式本身根本不是颜色代码，除非有东西去翻译它。把 &c 粘贴进一个期望 MiniMessage 的插件，玩家看到的就是字面的字符。
传统代码的颜色不够用
分节符系统携带一组固定的颜色字母以及格式开关。它无法表达任意颜色。十六进制是后来才出现的，而 BungeeCord 形式逐字符编码——&x 后跟六个带 & 前缀的十六进制数字，这就是它看起来那么长的原因。
MiniMessage 直接接受 #ff0000。JSON 则把同样的十六进制作为字符串值接受。
Java 和 Bedrock 并不一致
Bedrock 也使用分节符，但它的颜色集合以及处理格式重置的方式与 Java 不同。一个在 Java 服务器上渲染正常的字符串，在 Bedrock 客户端上可能显示出多余字符，而跨平台代理往往在两者之间做转换，而不是直接透传文本。如果你的服务器接受 Bedrock 玩家，请在两端都测试输出。
嵌套陷阱
传统代码是有状态的：一个颜色代码会重置格式，所以 §l§cBold 是红色加粗，但 §c§lBold 只是加粗红色，直到下一个颜色代码清除加粗为止。MiniMessage 是一棵树——<red><bold>text</bold></red> 会干净地闭合。把嵌套的 MiniMessage 字符串转换成传统代码会丢失结构，因为传统格式没有闭合标签。
转义
MiniMessage 把 < 视为语法。一个名叫 <Steve> 的玩家会破坏任何把其名字当作组件解析的插件。传统格式对 & 有同样的问题，这就是为什么许多插件要求使用 && 或一个配置开关来转义它。
把文本写一次，选择你的插件真正解析的方言，然后从 Server Text Studio 复制确切的字符串。