是該文檔錯誤有關解釋\ XHH

這是從主TCL DOC：是該文檔錯誤有關解釋 XHH

\xhh The hexadecimal digits hh give an eight-bit hexadecimal value for the 
Unicode character that will be inserted. Any number of hexadecimal digits may be 
present; however, **all but the last two are ignored** (the result is always a 
one-byte quantity).

我的疑問是這一部分，all but the last two are ignored。這裏是我的實驗：

>set a "\x22" 
" 
>set a "\x2230" 
"30

所以你可以看到，這是採取第2個十六進制數字，其餘都只是當作普通的字符。

我想念什麼？

[編輯]好像我是對的，這裏是從tcl8.6的parser.c：

860  case 'x': 
861   count += TclParseHex(p+1, (numBytes > 3) ? 2 : numBytes-2, &result);

所以只能採取第一個直接2個位數。奇怪，爲什麼沒有人發現這個文檔錯誤。

來源

2014-06-07 my_question

這是一個行爲從Tcl 8.5（和之前）改爲8.6的地方。這是一個錯誤修復，因爲舊的行爲是如此怪異以至於沒人想到它。（或西班牙宗教裁判所，但我離題...）

在8.6，the documentation says：

\ X HH
十六進制數字HH（一個或兩個）給出將插入的Unicode字符的八位十六進制值。 Unicode字符的高位爲0。

在8.5，the documentation says：

\ X HH
十六進制數字HH得到八比特十六進制值爲將被插入的Unicode字符。任何數量的十六進制數字都可能存在;但是，除了最後兩個之外的所有內容都被忽略（結果總是一個字節的數量）。 Unicode字符的高位將爲0.

區別很明顯，8.5和8.6在此處的行爲不同。這一變化是由於TIP #388「將Unicode文字擴展到BMP之後」（其中一些修復程序的一部分，其中一些必須推遲到8.6之後，由於對ABI的影響），並於2011年9月投票通過;項目負責人是Jan Nijtmans。我記得爲這個提示投了票，而且那個修復是我很高興的事情。

對不起，它沒有被標記爲潛在的不兼容性。錯過了那個（可能是因爲舊的行爲如此糟糕以至於沒有人真的相信我們很久以前沒有修好它......）

來源

2014-06-08 16:45:55

是該文檔錯誤有關解釋\ XHH

回答

相關問題