ansi編碼的漢字符，必須對文本從頭到尾順序掃描，一個錯位，後面全成亂碼，這就是我們常見的亂碼成因。這種編碼是舊系統的經典用法，并不好用，在那個時代過來的人都知道那很麻煩，不然編程語言也不至於發展到以多字節爲單元的字符編碼。ansi和utf8一樣是可變長度編碼，弊端是一樣的。在Windows系統中，是utf-16編碼，即固定長度的2字節編碼，好處理得多；另外還有更全面的utf-32編碼，即4字節的。

在GBK編碼的系統中（當前的中文Windows系統就是這種編碼），其内碼範圍是0x8140~0xfefe，第二字節未必是大於0x80，再用以前GB2312那種靠高位是1的方法來判斷，是不行的。在樓主的問題中，數據流是倒過來掃描，先讀到第二字節，這個時候不能僅看該自己的高位是否爲1來判斷，還需要預讀下一個字節才成。哪有這麽簡單！與其把算法弄複雜，其實如前有人所言，乾脆把整個文本順序讀入（讀入的同時就把數據變成utf-16編碼的）了再倒置還來得方便。

在.net基礎類庫中，有現成的編碼轉換庫函數，能把各種編碼互相轉換，這是從Windows7開始就力推的系統API，在Windows10後的大一統Windows下全是這種API，不再是Win32 API了。Win32 API雖然也有轉換函數，但很複雜，我也不能完全弄懂。當然，如果你假定GB2312就夠了，那麽也可以繼續沿用舊的方法，但那樣沒太大意義了。何況，這種倒置的需求，沒什麽實際的作用，花心思做它，似乎劃不來。

vb里都是unicode，占两个字节，asc西文字符前面加个为0的字节，这样应该怎么处理都不会出现半个汉字的问题的。不过好像txt文件里的汉字永远是用汉字内码表示的，两个字节的最高位均为1。

汉字好像要两个两个的倒

所有文件都是以字節爲單位儲存的，問題是程序怎麽解釋其意義而已。這正如int和char，我們把int視爲4個char，或把它視爲一個32位整數，或把它視爲2個16位整數，都是自由的。解釋不通，呈現的結果就不同，也就是所謂的“亂碼”，亂碼衹是沒按你預想的方案解釋罷了。