簡介
ANSI序列是在二十世紀七十年代引入的標準，用以取代特定於終端供應商的序列，並在二十世紀八十年代早期開始在計算機設備市場上廣泛使用。與早期缺少游標移動功能的系統相比，新生的電子公告板系統使用ANSI序列改進其顯示。正是因為這個原因，ANSI序列變成了所有製造商共同採用的標準。
在21世紀，儘管硬體文本終端已經越來越少了，但ANSI標準依然存在，因為大多數終端模擬器會對部分ANSI轉義序列進行解釋。一個值得注意的例外是，在微軟Windows 10更新TH2之前，Windows作業系統的Win32控制台是不支持ANSI轉義序列的。
歷史
最初，幾乎每個視頻終端製造商都各自添加了特定的轉義序列用於執行一些特殊操作，比如把游標置於螢幕上的某個位置。舉例來說，VT52終端允許通過傳送ESC字元、y字元，後面跟上兩個等於x,y位置的數值加上32的字元（這是為了從ASCII空格字元開始，並避開控制字元），將游標置於螢幕上的x,y位置。
由於這些序列對於不同的終端並不一樣，因此人們不得不開發了一些複雜的庫（比如termcap）和實用程式（比如tput），以便程式可以使用同一套API應對各種終端。另外，在很多終端中需要藉助字元的二進制值傳送數字（如行和列）。對於某些程式語言，以及內部不使用ASCII的系統來說，把數字轉換為正確的字元常常是有困難的，甚至完全做不到。
ANSI標準試圖解決這些問題。標準制訂了一種所有終端共用的指令集，並要求用ASCII的數字字元傳遞所有數值信息。該系列的第一個標準是1976年通過的ECMA-48。它是一系列字元編碼標準的延續，其中第一個是從1965年的ECMA-6，一個7位標準，ISO 646就源自此標準。“ANSI轉義序列”的名稱可以追溯到1979年ANSI採用ANSI X3.64。此外，ANSI X3L2委員會與ECMA委員會TC 1合作制訂了一個幾乎一模一樣的標準。以上兩個標準合併為ISO 6429的國際標準。1994年，ANSI取消了其標準，以支持國際標準。
第一個支持這個標準的流行視頻終端是1978年推出的DigitalVT100。這個終端在市場上非常成功，引發了各種各樣的仿製品，其中最早和最流行的是1979年的Zenith Z-19。其他品牌還有QumeQVT-108，TelevideoTVI-970，WyseWY-99GT。另外，許多其他品牌的終端也不同程度地兼容可選的“VT100”、“VT103”或“ANSI”模式。 隨著越來越多的軟體（尤其是BBS系統）普及，越來越多的軟體依賴轉義序列起作用，導致幾乎所有新的終端和終端模擬器都支持了此標準。
1981年，ANSI X3.64被美國政府採用（FIPS86）。後來，美國政府停止複製行業標準，所以FIPS 86又被撤回了。
ECMA-48已經經歷了多次更新換代，目前是從1991年開始的第5版。它也被ISO和IEC用作標準 ISO/IEC 6429。
平台支持
隨著諸多BBS和線上服務廣泛使用ANSI，到20世紀80年代中期，ANSI幾乎得到了全平台支持。儘管許多作業系統在標準文本輸出中越來越多地支持ANSI，但大多數情況下是以終端模擬器的形式（例如Unix上的xterm，或MacOS上的OS X Terminal或ZTerm，以及IBM PC上的許多通信程式）。
Unix和AmigaOS都在作業系統中包含了對ANSI的一些支持，導致在這些平台上運行的程式廣泛使用ANSI。類Unix作業系統可以通過像termcap和curses庫之類的庫來生成ANSI代碼，許多軟體使用這些庫升級顯示方式。這些庫也應該支持非ANSI終端，但是現在很少有人測試，所以很可能已經不起作用了。許多遊戲和shell腳本直接輸出ANSI序列（如彩色的提示信息），因此無法在不支持ANSI的終端上運行。
AmigaOS不僅支持輸出到螢幕上的文本使用ANSI序列，印表機驅動程式也支持（用AmigaOS的專有擴展），並將它們轉換為與特定印表機實際通信所需的代碼。
儘管ANSI很普及，卻並沒有得到全平台支持。比如原始的“經典”Mac OS就沒有內置對ANSI的支持，再比如Atari ST使用的是VT52改編的命令系統，用一些擴展程式支持顏色顯示。
Windows和DOS
MS-DOS 1.x不支持ANSI或任何其他轉義序列，只有少數控制字元（BEL、CR、LF、BS）可以由底層BIOS解釋，所以幾乎不可能做出任何全螢幕應用程式。所有顯示效果都必須通過BIOS調用，或者直接控制IBM PC硬體來完成，調用速度非常慢。
DOS 2.0引入了添加設備驅動程式來支持ANSI轉義序列的功能（事實上的標準是ANSI.SYS，但也使用了ANSI.COM、NANSI.SYS和ANSIPLUS.EXE等其他程式。因為繞過了BIOS，所以這些程式的速度比以前快了不少）。但由於實際運行速度仍然比較慢，以及默認並沒有安裝，所以還是很少得到利用。應用程式往往還是繼續用直接控制硬體的方式來顯示所需的文本。ANSI.SYS和類似的驅動程式繼續在Windows 9x上工作，直到Windows Me，在NT派生系統中用於在NTVDM下執行的16位傳統程式。
Win32控制台完全不支持ANSI轉義序列。不過有一些控制台的替代品或者附加軟體具有解釋程式輸出的ANSI轉義序列的功能，例如JP Software的TCC（以前的4NT）、Michael J. Mefford的ANSI.COM、Jason Hood的ANSICON和Maximus5的ConEmu。有一個Python軟體包在內部解釋了列印文本中的ANSI轉義序列，將它們轉換為系統調用來操縱顏色和游標位置，以便更容易地將使用ANSI的Python代碼移植到Windows。
2016年，在Windows 10發布“Threshold 2”時，微軟開始在控制台應用程式中支持ANSI轉義序列，使得從Unix移植軟體或者遠程訪問Unix變得更容易。
轉義序列
序列具有不同的長度。所有序列都以ASCII字元 ESC（27 /十六進制0x1B）開頭，第二個位元組則是0x40–0x5F（ASCII ）範圍內的字元。
標準規定，在8位環境中，這兩個位元組的序列可以合併為0x80-0x9F範圍內的單個位元組（詳情請參閱C1控制代碼）。但是，在現代設備上，這些代碼通常用於其他目的，例如UTF-8的一部分或CP-1252字元，因此並不使用這種合併的方式。
除ESC之外的其他C0代碼（通常是BEL，BS，CR，LF，FF，TAB，VT，SO和SI）在輸出時也可能會產生與某些控制序列相似或相同的效果。
| 序列 | C1 | 名稱 | 作用 |
| ESC N | 0x8e | SS2 – Single Shift Two | 從其中一個替代字元集中選擇一個字元。在xterm中，SS2選擇G2字元集，SS3選擇G3字元集。 |
| ESC O | 0x8f | SS3 – Single Shift Three | |
| ESC P | 0x90 | DCS – 設備控制字元串（Device Control String） | 控制設備。在xterm中，這個序列的使用包括定義用戶自定義的密鑰，以及請求或設定Termcap/Terminfo數據。 |
| ESC [ | 0x9b | CSI - 控制序列導入器（Control Sequence Introducer） | 大部分有用的序列，請參閱下一節。結束於ASCII 64到126 (@到~/十六進制0x40到0x7E). |
| ESC \ | 0x9c | ST – 字元串終止（String Terminator） | 終止其他控制項（包括APC，DCS，OSC，PM和SOS）中的字元串。 |
| ESC ] | 0x9d | OSC – 作業系統命令（Operating System Command） | 啟動作業系統使用的控制字元串。OSC序列與CSI序列相似，但不限於整數參數。通常，這些控制序列由ST終止。在xterm中，它們也可能被BEL終止。例如，在xterm中，視窗標題可以這樣設定：OSC 0;this is the window title BEL。 |
| ESC X | 0x98 | SOS – 字元串開始（Start of String） | 引用由ST終止的一串文本的參數。這些字元串控制序列的用途由應用程式或私有規則來定義。這些函式沒有實現，參數被xterm忽略。 |
| ESC ^ | 0x9e | PM – 私有訊息（Privacy Message） | |
| ESC _ | 0x9f | APC – 應用程式命令（Application Program Command） | |
| ESC c | RIS – 重置為初始狀態（Reset to Initial State） | 將設備重置為原始狀態。可能包括（如果適用的話）：重置圖形格式，清除制表符，重置為默認字型等等。 |
按下鍵盤上的特殊鍵，以及輸出xterm CSI、DCS或OSC序列，常常用於產生從終端傳送到計算機的CSI，DCS或OSC序列，就像用戶使用鍵盤輸入的一樣。
