C# 构建十六进制字符串
如何以十六进制表示法构建转义序列字符串。
示例:
string s = "\x1A"; // this will create the hex-value 1A or dec-value 26
我希望能够像这样构建十六进制值在 00 到 FF 之间的字符串(在本例中为 1B)
string s = "\x" + "1B"; // Unrecognized escape sequence
也许还有另一种制作十六进制字符串的方法...
How do I build an escape sequence string in hexadecimal notation.
Example:
string s = "\x1A"; // this will create the hex-value 1A or dec-value 26
I want to be able to build strings with hex-values between 00 to FF like this (in this example 1B)
string s = "\x" + "1B"; // Unrecognized escape sequence
Maybe there's another way of making hexadecimal strings...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
请尽量避免使用
\x
转义序列。 它很难阅读,因为它停止的位置取决于数据。 例如,这两个字符串乍一看有多大区别?在前者中,“\x9”是制表符 - 转义序列在那里停止,因为“G”不是有效的十六进制字符。 在第二个字符串中,“\x9Bad”都是转义序列,留下一些随机的 Unicode 字符和“compiler”。
我建议您使用 \u 转义序列:(
当然,对于选项卡,您可以使用
\t
但我希望您明白我的意思...)这有点偏离原来的问题当然,但这已经得到回答了:)
Please try to avoid the
\x
escape sequence. It's difficult to read because where it stops depends on the data. For instance, how much difference is there at a glance between these two strings?In the former, the "\x9" is tab - the escape sequence stops there because 'G' is not a valid hex character. In the second string, "\x9Bad" is all an escape sequence, leaving you with some random Unicode character and " compiler".
I suggest you use the \u escape sequence instead:
(Of course for tab you'd use
\t
but I hope you see what I mean...)This is somewhat aside from the original question of course, but that's been answered already :)
您不在字符串中存储十六进制值。
可以,但它只是一个字符串,并且必须转换为整数或字节才能实际读取其值。
不过,您可以将十六进制值作为文字分配给 int 或字节:
因此,可以轻松地将十六进制文字传递到字符串中:
这将创建此字符串“126 hex test”。
但我认为这不是你想要的?
You don't store hexadecimal values in strings.
You can, but it would just be that, a string, and would have to be cast to an integer or a byte to actually read its value.
You can assign a hexadecimal value as a literal to an int or a byte though:
So, its easily possible to pass an hexadecimal literal into your string:
Which would create this string "126 hex test".
But I don't think that's what you wanted?
十六进制 16 位 unicode 字符代码有一个“\u”转义码。
There's an '\u' escape code for hexadecimal 16 bits unicode character codes.
接受的答案包含以下声明:
通常这是真的。
适合将奇怪的通常不可打印的字符存储在字符串中的问题范围相当小。 但工作技能“整合”似乎正在上升,这是你可能想做OP建议的地方。
如果您正在处理文件,您可能会发现数据中存在需要忽略的自定义字符集。
在这种情况下,在字符串中存储不可打印的字符(制表符、转义符等)可能是一种可行的方法。
我将这些“忽略的字符”称为空白,即使本示例中的一些字符是可打印的,并且术语空白通常仅指不可打印的字符。< br>
这样写比较容易。
例如,您可能要求以下是空白:
但这些不是空格:
空格的定义将阻止您使用内置的 C# 函数。
它还将阻止使用包含字符串函数的大多数常见库(例如 Extensions.cs) 。
只读字符串whiteSpace = "\u0032\t\u00A0_-";
在此示例中,您可以对前面的字符串使用 Contains 来检测哪些字符是空格(使用上面给出的定义或任何其他自定义定义)。
如果用户/业务分析师有在开发期间和/或发布前不久更改需求的历史,则将这些特殊字符加载到字符串中是一个特别好的选择。
(字符串很容易更改,并且需要对其他系统进行最少的重新测试)
我无权向已接受的答案添加评论,我猜是因为它的年龄。 鉴于出现的“集成”工作数量不断增加,这个问题和这个答案所提出的观点都与当今的许多开发人员相关(在提出这个问题 15 年后)。
The accepted answer contains the statement:
Often this is true.
The domain of problems that lends itself to storing weird often non-printable characters a string, is rather small. But the jobs skill "integration" seems to be on the rise, and that is a place where you may want to do what the OP suggests.
If you are processing files, you may see that there is a custom set of characters that need to be ignored within the data.
In that case, storing non-printable characters (tab, escape, etc.) in a string can be the way to go.
I'll call these "ignored characters" white space even though a few in this example are printable, and the term white space often refers only to non-printable characters.
It is easier to write it that way.
For example you may have the requirement that the following are white space:
but that these are not white space:
That definition of white space will prevent you from using the built-in C# functions.
It will also prevent using most common libraries containing string functions (such as Extensions.cs).
readonly string whiteSpace = "\u0032\t\u00A0_-";
In this example you can use Contains against the preceding string to detect which characters are white space (using the definition given above or any other custom definition).
Loading those special characters into a string is an especially good choice if the users/business analyst have a history of changing the requirements during development and/or shortly before release.
(A string is easy to change, and requires minimal retesting against other systems)
I don't have permission to add a comment to the accepted answer, I guess because of its age. Given the increasing number of "integration" jobs which are appearing, this question and the point this answer makes are both relevant to a lot of developers today (15 years after it was asked).