blocks|key|2909064|text|更新|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2909065|基于使用C#编译器%2Bildasm.exe的实验:可能没有转义字符列表的原因是因为转义字符太少:准确地说是6个。|2909066|从ildasm生成的IL，到Visual+Studio2010编译的C#程序|2909067|传统空格字符严格转义为ASCII.|2909068|Three+|unordered-list-item|2909069|\t：0x09：(tab)|CODE|2909070|\n：0x0A：(newline)|2909071|\r：0x0D：(|2909072|+return)|2909073|2909074|：(+|2909075|IL是严格转义的|2909076|2909077|2909078|​|2909079|问题将转义三个标点符号：|2909080|\"：0x22：(|2909081|：0x3F：(问题mark)|2909082|\\：0x5C：(backslash)|2909083|2909084|2909085|2909086|2909087|在文字字符串0x20+-+0x7E中仅原封不动地包含以下字符，(不包括三个标点符号和其他字符，包括0x20以下的ASCII控制字符和0x7F以上的所有字符)转换为字节数组。或者更确切地说，包含除上面的92个文字字符和6个转义字符之外的任何字符的任何字符串都被转换为字节数组，其中字节是UTF-16字符串的little-endian字节。|2909088|2909089|示例1:+0x7E以上的ASCII+:简单重音符号(U%2B00E9)|2909090|C#："é"或"\u00E9"变为(E9字节在前)|2909091|ldstr++++++bytearray+(E9+00+)|code-block|syntax|javascript|2909092|示例2:+U%2B2211-16:求和符号∑(UTF)|2909093|C#："∑"或"\u2211"变为(11字节在前)|2909094|ldstr++++++bytearray+(11+22+)|2909095|示例3:+UTF-32：Double-struck+mathematical+(U%2B1D538)|2909096|C#：""或UTF-16代理项对"\uD835\uDD38"变为(字符内的字节颠倒，但双字节字符按整体顺序排列)|2909097|ldstr++++++bytearray+(35+D8+38+DD+)|2909098|示例4:字节数组转换适用于包含非Ascii字符的整个字符串|2909099|C#："In+the+last+decade,+the+German+word+\"über\"+has+come+to+be+used+frequently+in+colloquial+English."变成了|2909100|ldstr++++++bytearray+(49+00+6E+00+20+00+74+00+68+00+65+00+20+00+6C+00++
++++++++++++++++++++++61+00+73+00+74+00+20+00+64+00+65+00+63+00+61+00++
++++++++++++++++++++++64+00+65+00+2C+00+20+00+74+00+68+00+65+00+20+00++
++++++++++++++++++++++47+00+65+00+72+00+6D+00+61+00+6E+00+20+00+77+00++
++++++++++++++++++++++6F+00+72+00+64+00+20+00+22+00+FC+00+62+00+65+00++
++++++++++++++++++++++72+00+22+00+20+00+68+00+61+00+73+00+20+00+63+00++
++++++++++++++++++++++6F+00+6D+00+65+00+20+00+74+00+6F+00+20+00+62+00++
++++++++++++++++++++++65+00+20+00+75+00+73+00+65+00+64+00+20+00+66+00++
++++++++++++++++++++++72+00+65+00+71+00+75+00+65+00+6E+00+74+00+6C+00++
++++++++++++++++++++++79+00+20+00+69+00+6E+00+20+00+63+00+6F+00+6C+00++
++++++++++++++++++++++6C+00+6F+00+71+00+75+00+69+00+61+00+6C+00+20+00++
++++++++++++++++++++++45+00+6E+00+67+00+6C+00+69+00+73+00+68+00+2E+00+)|2909101|2909102|直接说"you‘t“(查找MSIL字符串转义列表)，但这里有一些有用的花边新闻...|2909103|包含CIL的严格定义的ECMA-335并没有指定哪些字符必须在QSTRING文本中转义，只指定它们可以使用反斜杠\字符进行转义。最重要的注意事项是：|2909104|2909105|Unicode文本表示为octals，而不是十六进制(即\042，而不是\u0022).|2909106|Strings可以使用\字符跨多行进行扩展--请参阅下面的|2909107|2909108|唯一明确提到的转义是制表符\t、换行符\n和八进制数字转义。这对您来说有点麻烦，因为C#没有八进制文字--您必须自己进行提取和转换，比如使用Convert.ToInt32([string],+8)方法。|2909109|除此之外，转义的选择对于规范中描述的“假设的IL汇编器”来说是“特定于实现的”。所以你的问题正确地问到了MSIL的规则，这是微软对CIL的严格实现。据我所知，MS还没有记录他们的逃生选择。至少问问Mono的人他们用的是什么是有帮助的。除此之外，可能还需要自己生成列表--编写一个程序，为每个字符\u0000声明一个字符串文字--不管是什么，看看编译后的ldstr语句是什么。如果我先找到它，我一定会发布我的结果。|2909110|补充说明：|2909111|要正确解析*IL字符串文字--称为QSTRINGS或SQSTRINGS+--您需要考虑的不仅仅是字符转义。以代码内字符串连接为例(这是Partition+II：：5.2中的原文)：|2909112|2909113|+"%2B“运算符可用于连接字符串文字。这样，通过使用"%2B“并在每一行上添加一个新字符串，可以将一个长字符串分成多行。另一种方法是使用"\“作为行中的最后一个字符，在这种情况下，该字符及其后面的换行符不会输入到生成的字符串中。忽略"\“和下一行第一个非空白字符之间的任何空白字符(空格、换行符、回车符和制表符)。注意:要在QSTRING中包含双引号字符，请使用八进制转义序列。结束音符|blockquote|2909114|2909115|示例:以下字符串的结果相当于"Hello+World+from+CIL!"：|2909116|2909117|ldstr+"Hello+"+%2B+"World+"+%2B+"from+CIL!"

ldstr+"Hello+World\+
+++++++\040from+CIL!"|2909118|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Mathematical_alphanumeric_symbols|1|http://www.ecma-international.org/publications/standards/Ecma-335.htm^0|0|2|0|0|0|B|5|0|0|0|2|0|0|2|0|0|2|1|1|0|0|0|0|0|0|0|0|2|1|1|0|2|1|0|0|0|0|48|D|0|0|0|3|3|7|8|I|2|0|0|0|3|3|7|8|I|2|0|0|C|Q|0|0|3|2|G|E|0|0|0|3|2S|0|0|0|0|1K|1|B|8|1|0|0|C|6|S|4|10|6|0|B|1|0|0|D|2|J|2|1Y|S|M|3|0|43|6|4W|5|0|0|5|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|3F|8|@$9|3G|A|3H|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|3I|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|3J|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|3K|8|@$9|3L|A|3M|B|C]]|D|@]|E|$]]|$1|L|3|M|5|N|7|3N|8|@]|D|@]|E|$]]|$1|O|3|P|5|N|7|3O|8|@$9|3P|A|3Q|B|Q]]|D|@]|E|$]]|$1|R|3|S|5|N|7|3R|8|@$9|3S|A|3T|B|Q]]|D|@]|E|$]]|$1|T|3|U|5|N|7|3U|8|@$9|3V|A|3W|B|Q]]|D|@]|E|$]]|$1|V|3|W|5|N|7|3X|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|3Y|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|3Z|8|@]|D|@]|E|$]]|$1|10|3|11|5|N|7|40|8|@]|D|@]|E|$]]|$1|12|3|-4|5|6|7|41|8|@]|D|@]|E|$]]|$1|13|3|-4|5|6|7|42|8|@]|D|@]|E|$]]|$1|14|3|15|5|6|7|43|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|44|8|@]|D|@]|E|$]]|$1|18|3|19|5|N|7|45|8|@$9|46|A|47|B|Q]]|D|@]|E|$]]|$1|1A|3|1B|5|N|7|48|8|@]|D|@]|E|$]]|$1|1C|3|1D|5|N|7|49|8|@$9|4A|A|4B|B|Q]]|D|@]|E|$]]|$1|1E|3|-4|5|6|7|4C|8|@]|D|@]|E|$]]|$1|1F|3|-4|5|6|7|4D|8|@]|D|@]|E|$]]|$1|1G|3|15|5|6|7|4E|8|@]|D|@]|E|$]]|$1|1H|3|-4|5|6|7|4F|8|@]|D|@]|E|$]]|$1|1I|3|1J|5|N|7|4G|8|@$9|4H|A|4I|B|C]]|D|@]|E|$]]|$1|1K|3|-4|5|6|7|4J|8|@]|D|@]|E|$]]|$1|1L|3|1M|5|6|7|4K|8|@]|D|@]|E|$]]|$1|1N|3|1O|5|6|7|4L|8|@$9|4M|A|4N|B|Q]|$9|4O|A|4P|B|Q]|$9|4Q|A|4R|B|Q]]|D|@]|E|$]]|$1|1P|3|1Q|5|1R|7|4S|8|@]|D|@]|E|$1S|1T]]|$1|1U|3|1V|5|6|7|4T|8|@]|D|@]|E|$]]|$1|1W|3|1X|5|6|7|4U|8|@$9|4V|A|4W|B|Q]|$9|4X|A|4Y|B|Q]|$9|4Z|A|50|B|Q]]|D|@]|E|$]]|$1|1Y|3|1Z|5|1R|7|51|8|@]|D|@]|E|$1S|1T]]|$1|20|3|21|5|6|7|52|8|@]|D|@$9|53|A|54|1|55]]|E|$]]|$1|22|3|23|5|6|7|56|8|@$9|57|A|58|B|Q]|$9|59|A|5A|B|Q]]|D|@]|E|$]]|$1|24|3|25|5|1R|7|5B|8|@]|D|@]|E|$1S|1T]]|$1|26|3|27|5|6|7|5C|8|@]|D|@]|E|$]]|$1|28|3|29|5|6|7|5D|8|@$9|5E|A|5F|B|Q]]|D|@]|E|$]]|$1|2A|3|2B|5|1R|7|5G|8|@]|D|@]|E|$1S|1T]]|$1|2C|3|-4|5|6|7|5H|8|@]|D|@]|E|$]]|$1|2D|3|2E|5|6|7|5I|8|@]|D|@]|E|$]]|$1|2F|3|2G|5|6|7|5J|8|@$9|5K|A|5L|B|Q]]|D|@$9|5M|A|5N|1|5O]]|E|$]]|$1|2H|3|-4|5|6|7|5P|8|@]|D|@]|E|$]]|$1|2I|3|2J|5|N|7|5Q|8|@$9|5R|A|5S|B|C]|$9|5T|A|5U|B|Q]|$9|5V|A|5W|B|Q]]|D|@]|E|$]]|$1|2K|3|2L|5|N|7|5X|8|@$9|5Y|A|5Z|B|Q]]|D|@]|E|$]]|$1|2M|3|-4|5|6|7|60|8|@]|D|@]|E|$]]|$1|2N|3|2O|5|6|7|61|8|@$9|62|A|63|B|Q]|$9|64|A|65|B|Q]|$9|66|A|67|B|Q]|$9|68|A|69|B|C]]|D|@]|E|$]]|$1|2P|3|2Q|5|6|7|6A|8|@$9|6B|A|6C|B|Q]|$9|6D|A|6E|B|Q]]|D|@]|E|$]]|$1|2R|3|2S|5|6|7|6F|8|@$9|6G|A|6H|B|C]]|D|@]|E|$]]|$1|2T|3|2U|5|6|7|6I|8|@]|D|@]|E|$]]|$1|2V|3|-4|5|6|7|6J|8|@]|D|@]|E|$]]|$1|2W|3|2X|5|2Y|7|6K|8|@]|D|@]|E|$]]|$1|2Z|3|-4|5|6|7|6L|8|@]|D|@]|E|$]]|$1|30|3|31|5|6|7|6M|8|@]|D|@]|E|$]]|$1|32|3|-4|5|6|7|6N|8|@]|D|@]|E|$]]|$1|33|3|34|5|1R|7|6O|8|@]|D|@]|E|$1S|1T]]|$1|35|3|-4|5|6|7|6P|8|@]|D|@]|E|$]]]|36|$37|$5|38|39|3A|E|$3B|3C]]|3D|$5|38|39|3A|E|$3B|3E]]]]

Update

Based on experimentation using the C# compiler + ildasm.exe: perhaps the reason there is no list of escaped characters is because there are so few: precisely 6. 

Going from the IL generated by ildasm, from C# programs compiled by Visual Studio 2010:

<ul>
<li>IL is strictly ASCII.</li>
<li>Three traditional whitespace characters are escaped

<ul>
<li><code>\t</code> : 0x09 : (tab)</li>
<li><code>\n</code> : 0x0A : (newline)</li>
<li><code>\r</code> : 0x0D : (carriage return)</li>
</ul></li>
<li>Three punctuation characters are escaped:

<ul>
<li><code>\"</code> : 0x22 : (double quote)</li>
<li><code>\?</code> : 0x3F : (question mark)</li>
<li><code>\\</code> : 0x5C : (backslash)</li>
</ul></li>
<li>Only the following characters are included intact in literal strings 0x20 - 0x7E, (not including the three punctuation characters)</li>
<li>All other characters, including the ASCII contrl characters below 0x20 and everything from 0x7F on up, are converted to byte arrays. Or rather, any string containing any character other than the 92 literal and 6 escaped characters above, is converted to a byte array, where the bytes are the little-endian bytes of a UTF-16 string. </li>
</ul>

Example 1: ASCII above 0x7E: A simple accented é (U+00E9)

C#: Either <code>"é"</code> or <code>"\u00E9"</code> becomes (<code>E9</code> byte comes first)

<pre><code>ldstr bytearray (E9 00 )
</code></pre>

Example 2: UTF-16: Summation symbol ∑ (U+2211)

C#: Either <code>"∑"</code> or <code>"\u2211"</code> becomes (<code>11</code> byte comes first)

<pre><code>ldstr bytearray (11 22 )
</code></pre>

Example 3: UTF-32: <a href="http://en.wikipedia.org/wiki/Mathematical_alphanumeric_symbols" rel="noreferrer">Double-struck mathematical</a> (U+1D538)

C#: Either <code>""</code> or UTF-16 surrogate pair <code>"\uD835\uDD38"</code> becomes (bytes within char reversed, but double-byte chars in overall order)

<pre><code>ldstr bytearray (35 D8 38 DD )
</code></pre>

Example 4: Byte array conversion is for an entire string containing a non-Ascii character

C#: <code>"In the last decade, the German word \"über\" has come to be used frequently in colloquial English."</code> becomes

<pre><code>ldstr bytearray (49 00 6E 00 20 00 74 00 68 00 65 00 20 00 6C 00 
 61 00 73 00 74 00 20 00 64 00 65 00 63 00 61 00 
 64 00 65 00 2C 00 20 00 74 00 68 00 65 00 20 00 
 47 00 65 00 72 00 6D 00 61 00 6E 00 20 00 77 00 
 6F 00 72 00 64 00 20 00 22 00 FC 00 62 00 65 00 
 72 00 22 00 20 00 68 00 61 00 73 00 20 00 63 00 
 6F 00 6D 00 65 00 20 00 74 00 6F 00 20 00 62 00 
 65 00 20 00 75 00 73 00 65 00 64 00 20 00 66 00 
 72 00 65 00 71 00 75 00 65 00 6E 00 74 00 6C 00 
 79 00 20 00 69 00 6E 00 20 00 63 00 6F 00 6C 00 
 6C 00 6F 00 71 00 75 00 69 00 61 00 6C 00 20 00 
 45 00 6E 00 67 00 6C 00 69 00 73 00 68 00 2E 00 )
</code></pre>

<hr>

Directly, "you can't" (find a list of MSIL string escapes), but here are some helpful tidbits...

<a href="http://www.ecma-international.org/publications/standards/Ecma-335.htm" rel="noreferrer">ECMA-335</a>, which contains the strict definition of CIL, does not specify which characters must be escaped in QSTRING literals, only that they may be escaped using the backslash <code>\</code> character. The most important notes are: 

<ul>
<li>Unicode literals are presented as octals, not hexadecimal (i.e. <code>\042</code>, not <code>\u0022</code>).</li>
<li>Strings can be spread accross multiple lines using the <code>\</code> character--see below </li>
</ul>

The only explicitly mentioned escapes are tab <code>\t</code>, linefeed <code>\n</code>, and octal numeric escapes. This is a bit annoying for you purposes since C# does not have an octal literal -- you'll have to do your own extraction and conversion, such as by using the <code>Convert.ToInt32([string], 8)</code> method. 

Beyond that the choice of escapes is "implementation-specific" to the "hypothetical IL assembler" described in the spec. So your question rightly asks about the rules for MSIL, which is Microsoft's strict implementation of CIL. As far as I can tell, MS has not documented their choice of escapes. It could be helpful at least to ask the Mono folks what they use. Beyond that, it may be a matter of generating the list yourself -- make a program that declares a string literal for every character <code>\u0000</code> - whatever, and see what the compiled <code>ldstr</code> statements are. If I get to it first, I'll be sure to post my results.

Additional notes:

To properly parse *IL string literals -- known as QSTRINGS or SQSTRINGS -- you will have to account for more than just character escapes. Take in-code string concatenation, for example (and this is verbatim from Partition II::5.2): 

<blockquote>
 The "+" operator can be used to concatenate string literals. This way, a long string can be broken across multiple lines by using "+" and a new string on each line. An alternative is to use "\" as the last character in a line, in which case, that character and the line break following it are not entered into the generated string. Any white space characters (space, line-feed, carriage-return, and tab) between the "\" and the first non-white space character on the next line are ignored. [Note: To include a double quote character in a QSTRING, use an octal escape sequence. end note]
 
 Example: The following result in strings that are equivalent to "Hello World from CIL!":
</blockquote>

<pre><code>ldstr "Hello " + "World " + "from CIL!"

ldstr "Hello World\ 
 \040from CIL!"
</code></pre>

I've written a program (in C#) that reads and manipulates MSIL programs that have been generated from C# programs. I had mistakenly assumed that the syntax rules for MSIL string constants are the same as for C#, but then I ran into the following situation:

This C# statement

<pre><code>string s = "Do you wish to send anyway?";
</code></pre>

gets compiled into (among other MSIL statements) this

<pre><code>IL_0128: ldstr "Do you wish to send anyway\?"
</code></pre>

I wasn't expecting the backslash that is used to escape the question mark. Now I can obviously take this backslash into account as part of my processing, but mostly out of curiosity I'd like to know if there is a list somewhere of which characters get escaped when the C# compiler converts C# constant strings to MSIL constant strings.

Thanks.

Where can I find a list of escaped characters in MSIL string constants?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我已经编写了一个程序(用C#)来读取和操作从C#程序生成的MSIL程序。我错误地认为MSIL字符串常量的语法规则与C#的语法规则相同，但后来我遇到了以下情况：此C#语句string s = "Do you wish to send anyway?";编译成(和其他MSIL语句一起)这个IL_0128:  ldstr  ...

在哪里可以找到MSIL字符串常量中的转义字符列表？-腾讯云开发者社区-腾讯云

问在哪里可以找到MSIL字符串常量中的转义字符列表？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在哪里可以找到MSIL字符串常量中的转义字符列表？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在哪里可以找到MSIL字符串常量中的转义字符列表？
EN