ANTLRWorks 1.4.3 无法显示&毁坏 ASCII 字符
作为我上一个问题的新发展（ANTLRWorks 1.4。 3 无法正确读取扩展 ASCII 字符），我使用十六进制编辑器创建了一个简单的文本文件：
' ' '£' '°' 'ç'
或者以十六进制表示：
27 A0 27 20 27 A3 27 20 27 B0 27 20 27 E7 27
生成的文件在 Notepad++ 中读取良好。在 ANTLRWorks 1.4.3 中打开后，（扩展）ASCII 字符显示为方框。在行尾添加和删除空格后保存文件时，十六进制文件视图如下所示：
27 3F 20 27 A3 27 20 27 B0 27 20 27 3F
由于某种原因，撇号之间的初始空格 (20) 被截断为问号 (3F) 和特殊的 c带有变音符号 (E7) 和后面的撇号都被问号取代。
似乎扩展 ASCII 字符的存在会以某种方式导致出现严重错误。这里有人可以复制这个问题和/或提供可能的原因和解决方案吗？
提前致谢。
As a new development to my previous question (ANTLRWorks 1.4.3 can't properly read extended-ASCII characters), I created a simple text file using a hex editor:
' ' '£' '°' 'ç'
Or in hex:
27 A0 27 20 27 A3 27 20 27 B0 27 20 27 E7 27
The resulting file reads fine in Notepad++. Upon opening in ANTLRWorks 1.4.3 the (extended) ASCII characters are displayed as square boxes. Upon saving the file after adding and removing a space at the end of the line, the hexadecimal file view looks as follows:
27 3F 20 27 A3 27 20 27 B0 27 20 27 3F
For some reason the initial space (20) in between apostrophes got mutilated into a question mark (3F) and the special c with cedilla character (E7) and the apostrophe following it got both replaced by a question mark.
It seems that the presence of extended ASCII characters somehow results in things going horribly wrong. Can anyone here replicate this issue and/or offer a possible reason and solution?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以只使用 Unicode 转义符。假设你想匹配英文英镑符号，你会这样做：
而不是：
它们（应该）都匹配相同的字符，并且第一个很可能不会被破坏。
You could just use the Unicode escapes instead. Say you want to match the English pound sign, you'd do:
instead of:
They (should) both match the same character, and the first may very well not be mangled.