ANSI轉義序列

ANSI轉義序列是一種的轉義序列標準，用於控制影片文字終端上的游標位置、顏色和其他選項。在文字中嵌入確定的位元組序列，大部分以codice_1跳脫字元和"["字元開始，終端會把這些位元組序列解釋為相應的指令，而不是普通的字元編碼。ANSI序列是在二十世紀七十年代引入的標準，用以取代特定於終端供應商的序列，並在二十世紀八十年代早期開始在計算機裝置市場上廣泛使用。與早期缺少游標移動功能的系統相比，新生的電子公告板系統使用ANSI序列改進其顯示。正是因為這個原因，ANSI序列變成了所有制造商共同採用的標準。在21世紀，儘管硬體文字終端已經越來越少了，但ANSI標準依然存在，因為大多數終端模擬器會對部分ANSI轉義序列進行解釋。一個值得注意的例外是，在微軟Windows 10更新TH2之前，Windows作業系統的Win32控制檯是不支援ANSI轉義序列的。歷史.最初，幾乎每個影片終端製造商都各自添加了特定的轉義序列用於執行一些特殊操作，比如把游標置於螢幕上的某個位置。舉例來說，終端允許透過傳送codice_1字元、codice_3字元，後面跟上兩個等於x,y位置的數值加上32的字元，將游標置於螢幕上的x,y位置。由於這些序列對於不同的終端並不一樣，因此人們不得不開發了一些複雜的庫。對於某些程式語言，以及內部不使用ASCII的系統來說，把數字轉換為正確的字元常常是有困難的，甚至完全做不到。ANSI標準試圖解決這些問題。標準制訂了一種所有終端共用的指令集，並要求用ASCII的數字字元傳遞所有數值資訊。該系列的第一個標準是1976年透過的ECMA-48。它是一系列字元編碼標準的延續，其中第一個是從1965年的，一個7位標準，ISO 646就源自此標準。“ANSI轉義序列”的名稱可以追溯到1979年ANSI採用ANSI X3.64。此外，ANSI X3L2委員會與ECMA委員會TC 1合作制訂了一個幾乎一模一樣的標準。以上兩個標準合併為ISO 6429的國際標準。1994年，ANSI取消了其標準，以支援國際標準。第一個支援這個標準的流行影片終端是1978年推出的Digital 。這個終端在市場上非常成功，引發了各種各樣的仿製品，其中最早和最流行的是1979年的。其他品牌還有 QVT-108， TVI-970， WY-99GT。另外，許多其他品牌的終端也不同程度地相容可選的“VT100”、“VT103”或“ANSI”模式。 隨著越來越多的軟體普及，越來越多的軟體依賴轉義序列起作用，導致幾乎所有新的終端和終端模擬器都支援了此標準。1981年，ANSI X3.64被美國政府採用。後來，美國政府停止複製行業標準，所以FIPS 86又被撤回了。ECMA-48已經經歷了多次更新換代，目前是從1991年開始的第5版。它也被ISO和IEC用作標準ISO/IEC 6429。平臺支援.類Unix系統和AmigaOS.隨著諸多BBS和線上服務廣泛使用ANSI，到20世紀80年代中期，ANSI幾乎得到了全平臺支援。儘管許多作業系統在標準文字輸出中越來越多地支援ANSI，但大多數情況下ANSI支援是由終端模擬器完成的。Unix和AmigaOS都在作業系統中包含了對ANSI的一些支援，因此在這些平臺上執行的程式廣泛使用ANSI。 類Unix作業系統可以透過像和之類的庫來生成ANSI程式碼，許多軟體使用這些庫升級顯示方式。這些庫也應該支援非ANSI終端，但是現在很少有人測試，所以很可能已經不起作用了。許多遊戲和shell指令碼直接輸出ANSI序列，因此無法在不支援ANSI的終端上執行。AmigaOS不僅支援輸出到螢幕上的文字使用ANSI序列，還支援印表機驅動程式使用ANSI序列。儘管ANSI很普及，卻並沒有得到全平臺支援。比如原始的“經典”Mac OS就沒有內建對ANSI的支援，再比如Atari ST使用的是VT52改編的命令系統，需要用一些擴充套件程式來支援顏色顯示。Windows和DOS.MS-DOS 1.x不支援ANSI或任何其他轉義序列，只有少數控制字元可以由底層BIOS解釋，所以幾乎不可能做出任何全屏應用程式。所有顯示效果都必須透過BIOS呼叫，或者直接控制IBM PC硬體來完成，呼叫速度非常慢。DOS 2.0引入了新增裝置驅動程式來支援ANSI轉義序列的功能。但由於實際執行速度仍然比較慢，以及預設並沒有安裝，所以還是很少得到利用。應用程式往往還是繼續用直接控制硬體的方式來顯示所需的文字。ANSI.SYS和類似的驅動程式繼續在Windows 9x上工作，直到Windows Me，在NT衍生系統中用於在下執行的16位傳統程式。Win32控制檯完全不支援ANSI轉義序列。不過有一些控制檯的替代品或者附加軟體具有解釋程式輸出的ANSI轉義序列的功能，例如JP Software的TCC、Michael J. Mefford的ANSI.COM、Jason Hood的ANSICON和Maximus5的ConEmu。有一個Python軟體包在內部解釋了列印文字中的ANSI轉義序列，將它們轉換為系統呼叫來操縱顏色和游標位置，以便更容易地將使用ANSI的Python程式碼移植到Windows。2016年，在Windows 10釋出“Threshold 2”時，微軟開始在控制檯應用程式中支援ANSI轉義序列，使得從Unix移植軟體或者遠端訪問Unix變得更容易。這是與Windows Subsystem for Linux一起完成的，允許基於終端的類Unix軟體在Win32控制檯中使用轉義序列。2019年，微軟推出了Windows Terminal，並且正在用其替換掉Win32控制檯轉義序列.序列具有不同的長度。所有序列都以ASCII字元codice_1範圍內的字元。:5.3.a標準規定，在8位環境中，這兩個位元組的序列可以合併為0x80-0x9F範圍內的單個位元組。但是，在現代裝置上，這些程式碼通常用於其他目的，例如UTF-8的一部分或CP-1252字元，因此並不使用這種合併的方式。除ESC之外的其他C0程式碼在輸出時也可能會產生與某些控制序列相似或相同的效果。按下鍵盤上的特殊鍵，以及輸出xterm CSI、DCS或OSC序列，常常用於產生從終端傳送到計算機的CSI，DCS或OSC序列，就像使用者使用鍵盤輸入的一樣。CSI序列.CSI序列由codice_6、若干個“引數位元組”、若干個“中間位元組”，以及一個“最終位元組”組成。各部分的字元範圍如下：所有常見的序列都只是把引數用作一系列分號分隔的數字，如codice_7。缺少的數字視為0把0視為1，以使缺少引數的情況下有意義:F.4.2。一部分字元定義是“私有”的，以便終端製造商可以插入他們自己的序列而不與標準相沖突。包括引數位元組codice_10的使用，或者最終位元組0x70–0x7F（codice_11選擇RGB前景色codice_12選擇RGB背景色作為ISO / IEC國際標準8613-6採用的ITU的T.416資訊科技-開放文件體系結構和交換格式：字元內容體系結構給出了一個似乎不太受支援的替代版本：codice_13選擇RGB前景色codice_14選擇RGB背景色請注意，這裡使用了保留的“:”字元來分隔子選項，這可能是在實際實現中造成混淆的始作俑者。它還使用“3”作為第二個引數來指定使用青-品紅-黃方案的方案，“4”用於青-品紅-黃-黑的方案，後者使用上面標記為“unused”的位置作為黑色元件。還要注意，許多識別“:”作為分隔符的實現錯誤地忽視了色彩空間識別符號引數，並因此改變了其餘部分的位置。示例.codice_15 — 清除螢幕、。codice_16 — 使文字呈綠色。在MS-DOS上，一般綠色是暗淡的綠色，可以用codice_17啟用粗體使其變成明亮的綠色，或者將兩者合併為codice_18。MS-DOS ANSI.SYS用粗體狀態使字元變亮，閃爍狀態（透過codice_19)使背景色變成明亮模式。MS-DOS ANSI.SYS並不直接支援SGR程式碼90–97和100–107。codice_20 — 重新分配F10鍵的功能為傳送字串“DIR”和回車符到鍵盤快取中，在DOS命令列裡會顯示當前目錄的內容，用非標準的擴充套件使其包含一個字串引數。如果按標準，會認為字母D是序列的末尾。codice_21 — 儲存游標的位置。用序列codice_22會把游標重置回這個位置。假設當前的游標位置是7。某些終端需要使用DEC序列codice_27/codice_28，這得到了更廣泛的支援。使用Shell指令碼的示例.ANSI轉移程式碼常常用於UNIX和類UNIX終端，以提供語法高亮功能。例如，在相容的終端上，以下ls命令按型別對檔案和目錄的名稱進行顏色編碼。codice_29使用者可以在指令碼中使用轉義碼，將其作為標準輸出或標準錯誤輸出的一部分。例如，下面的GNU sed命令透過反顯“WARN”開頭的單詞的行，以及使用暗紅色背景色和亮黃色前景色顯示以“ERR”開頭的單詞的行來修飾make命令的輸出。突出顯示了設定ANSI程式碼的部分。make 2&gt;&amp;1 | sed -e 's/.*\bWARN.*/\x1b[7m&amp;\x1b[0m/i' -e 's/.*\bERR.*/\x1b[93;41 m&amp;\x1b[0m/i'以下Bash函式會使終端閃爍，直到使用者按下任意鍵。這個函式可以用於當一個冗長的命令終止時提醒使用者，用法如codice_30。下面這個命令可以重置控制檯，類似現代Linux系統的codice_31命令。然而，即使在較早的Linux系統和其他UNIX變體上，也應該能起作用。printf \\033c