Evennia、ANSI 和 Xterm256
所有現代 MUD 用戶端都支援顏色；儘管如此，所有客戶都遵守的標準
回到終端的舊時代，當談到顏色時，我們正在處理 ANSI 和 Xterm256
標準。
Evennia 在幕後透明地處理執行這些操作所需的所有程式碼
標準 - 因此，如果使用者連線的使用者端不支援顏色，或僅支援 ANSI
（16 種顏色），Evennia 將採取所有適當的步驟來確保將輸出調整為看起來
就在用戶端。
對於開發者來說，你只需要關心如何正確使用顏色tags
在你的MUD之內。最有可能的是，您將自動新增顏色來幫助頁面、描述
產生的文字等
您可以自由地將 ANSI 和 Xterm256 顏色 tags 混合在一起，但您應該注意一些
陷阱。 ANSI 和 Xterm256 在 Evennia 中共存，沒有衝突，但在很多方面它們“看不到”
彼此：ANSI特定顏色tags對Xterm定義的顏色沒有影響，我們會看到
在這裡。
ANSI
ANSI 有一組 16 種顏色，更準確地說：ANSI 有 8 種基本顏色，其中有 dark 和
_明亮_口味——深色_為_正常。顏色有：紅、綠、黃、藍、洋紅、
青色、白色和黑色。深色版本的白色通常被稱為灰色，而黑色版本通常被稱為灰色。
亮色版本為深灰色。在這裡，為了簡單起見，它們將被稱為黑暗和明亮：
亮/深黑、亮/深白。
MUD 使用者端的預設顏色是普通（深）白色配普通黑色（即：黑色配灰色）。
重要的是要理解，在 ANSI 標準中，明亮的顏色僅適用於文字（前景），而不適用於
到背景。 Evennia 允許透過 Xterm256 繞過此限制，但這樣做會影響
ANSI tags 的行為，正如我們將看到的。
另外，重要的是要記住 16 ANSI 顏色是約定，終端使用者可以
總是定製它們的外觀——他可能決定將綠色顯示為紅色，將深綠色顯示為藍色，
等等
ANSI Evennia 中的顏色 Tags
NOTE：為了方便閱讀，範例在後麵包含額外的空格
顏色tags（例如：|g green |b blue）。這樣做只是為了更容易
檢視 tags 與其上下文的分離；這不是一個好的做法
在現實生活中的編碼中。
讓我們繼續舉例。在您的 MUD 使用者端中輸入：
Evennia 應該正常輸出單字“Normal”（即：黑色上的灰色）和相反的“Negative”
顏色（即：灰色上的黑色）。
這非常簡單， |* ANSI invert tag 在前景和前景之間切換
背景－從現在開始，FG 和 BG 簡寫將用於指稱前景和
背景。
但請記住這一點：|* 已切換深白色和深黑色。
現在試試這個：
say |w Bright white FG |* Negative
你會注意到「Negative」這個字不是白底黑字，而是灰色的深灰色。這是為什麼呢？
不應該是白底黑字BG嗎？這裡發生了兩件事。
如前所述，ANSI 有 8 種基色，即深色。明亮的人是透過以下方式實現的
突出顯示基礎/深色/正常顏色，它們僅適用於FG。
這裡發生的事情是，當我們用 |w 設定亮白色 FG 時，Evennia 將其轉換為
高亮顯示 + 白色 FG 的 ANSI 序列。就Evennia的顏色tags而言，就好像我們輸入了：
say |h|!W Bright white FG |* Negative
此外，Highlight-On 屬性（僅適用於 BG！）在 FG/BG 之後保留
開關，這就是我們將黑色視為深灰色的原因：突出顯示使其亮黑色
（即：深灰色）。
至於 BG 也是灰色的，這是正常的，即：您看到正常白色（即：深白色 =
灰色）。請記住，由於沒有明亮的 BG 顏色，ANSI |* tag 將轉置任何 FG
正常/深色版本的顏色。所以這裡FG的亮白色在BG變成深白色了！在
現實中，它總是正常/深白色，除了在 FG 中由於
突出幕後tag。
讓我們用一些顏色來嘗試同樣的事情：
say |m |[G Bright Magenta on Dark Green |* Negative
同樣，由於 ANSI 規則，BG 保持黑暗，並且由於隱式 |h，FG 保持明亮
在|m中。
現在，讓我們看看如果我們設定一個明亮的BG然後反轉會發生什麼——是的，Evennia允許我們
去做吧，即使它不在 ANSI 的預期之內。
say |[b Dark White on Bright Blue |* Negative
在顏色反轉之前，BG 確實顯示為亮藍色，而在反轉之後（如預期），它是
深白色（灰色）。 BG 的亮藍色在反轉後倖存下來，並為我們提供了亮藍色 FG。
但這種行為很棘手，並不像看起來那麼簡單。
如果反演是純粹的ANSI，則亮藍色將被視為正常
藍色，並且應該在 FG 中轉換為普通藍色（畢竟沒有突出顯示）。
事實上，實際上這種顏色根本不是亮藍色，它只是它的 Xterm 版本！
為了示範這一點，請輸入：
say |[b Dark White on Bright Blue |* Negative |H un-bright
|H 高亮關閉 tag 應該變成深藍色最後一個詞；但事實並非如此，因為它
不能：為了強制使用非 ANSI 的亮背景色，Evennia 轉而使用 Xterm，而 Xterm 實體
不受 ANSI tags 影響！
因此，我們正在瞭解與顏色有關的所有混亂和可能的奇怪行為的核心tags
在Evennia中：除了Evennia從ANSI/Xterm到ANSI/Xterm的翻譯之外，這兩個系統是
彼此獨立透明。
上一個範例的亮藍色只是 ANSI 標準藍色的 Xterm 表示。
嘗試更改用戶端的預設設定，使藍色顯示為其他顏色，您將
然後意識到當 Evennia 傳送真實的 ANSI 顏色時的差異（將根據
到您的設定），而當它傳送該顏色的 Xterm 表示時（這將
始終按照 Evennia 的定義顯示）。
您必須記住，Xterm BG 或 FG 顏色的存在可能會影響您的方式
tags 處理文字。例如：
say |[b Bright Blue BG |* Negative |!Y Dark Yellow |h not bright
這裡 |h tag 不再影響 FG 顏色。即使它是透過 |! tag 更改的，
ANSI 由於 Xterm 顏色的侵入（亮藍色 BG，然後移至
FG 與 |*）。
所有意外的 ANSI 行為都是混合 Xterm 顏色的結果（無論是故意的還是
透過明亮的BG顏色）。 |n tag 會將內容恢復到位，ANSI tags 將正確回應
再次。所以，最後只是一個在使用 Xterm 顏色或明亮的 BG 時要小心的問題，並且
避免將它們與 ANSI tags 混合而不再次標準化（|n）。
試試這個：
say |[b Bright Blue BG |* Negative |!R Red FG
進而：
say |[B Dark Blue BG |* Negative |!R Red BG??
在第二個範例中，|! 更改了 BG 顏色，而不是 FG！事實上，奇怪的行為是
前一個例子中的一個，而不是後一個例子中的一個。當你用 |* 反轉 FG 和 BG 時，你實際上
顛倒他們的參考。這就是為什麼最後一個範例（具有正常/深色BG！）允許|!
更改 BG 顏色。在第一個範例中，再次出現 Xterm 顏色（亮藍色
BG) 這會更改預設行為。
試試這個：
say Normal |* Negative |!R Red BG
這是正常行為，正如您所看到的，它允許 |! 在
FG 和 BG 的反轉。
只要您瞭解 ANSI 的工作原理，處理顏色就應該很容易tags
避免 Xterm-ANSI 混合的陷阱。
最後一個例子：
say Normal |* Negative |* still Negative
表明 |* 只能連續工作一次，並且如果再次使用則不會（也不應該！）恢復。
在呼叫 |n tag 將 ANSI「重設」回正常狀態之前，它也不會產生任何影響。就是這樣
它是為了工作。
ANSI 根據簡單的基於狀態的機制執行，重要的是要了解使用 |n tag 重置的積極效果，而不是嘗試
可以這麼說，將其推向極限。
