C# 文件名中的0x202A：为什么？

我最近需要在一个varbinary映像上用SQL执行isnull操作。
到目前为止（ab）正常。 我很快编写了一个C#程序，从我的桌面读取no_image.png文件，并将字节作为十六进制字符串输出

该计划是这样开始的：

byte[] ba = System.IO.File.ReadAllBytes(@"‪D:\UserName\Desktop\no_image.png");
Console.WriteLine(ba.Length);
// From here, change ba to hex string

正如我之前无数次使用readallbytes一样，我觉得没什么大不了的
令我惊讶的是，我在ReadAllBytes上得到了一个“NotSupported”异常

我发现问题在于，当我右键单击文件时，转到“安全性”选项卡，复制粘贴对象名称（开始在右侧标记，并错误地向左移动），就会发生这种情况

而且这种情况只发生在Windows8.1（也许还有8）上，而不发生在Windows7上

当我输出有问题的字符串时：

public static string ToHexString(string input)
{
    string strRetVal = null;
    System.Text.StringBuilder sb = new System.Text.StringBuilder();

    foreach (char c in input)
    {
        sb.Append(((int)c).ToString("X2"));
    }

    strRetVal = sb.ToString();
    sb.Length = 0;
    sb = null;

    return strRetVal;
} // End Function ToHexString

string str = ToHexString(@"‪D:\UserName\Desktop\cookie.png");
string strRight = " (" + ToHexString(@"D:\UserName\Desktop\cookie.png") + ")"; // Correct value, for comparison

string msg = str + Environment.NewLine + "  " + strRight;
Console.WriteLine(msg);

我明白了：

202A443A5C557365724E616D655C4465736B746F705C636F6F6B69652E706E67
   (443A5C557365724E616D655C4465736B746F705C636F6F6B69652E706E67)

首先，当我在ascii中查找202A时，它是[space]+*

因为我既看不到空间也看不到星星，当我在谷歌上搜索202a时，我得到的第一件事就是德国刑法第202a条

但我认为这是一个不幸的巧合，它实际上是unicode控制字符“从左到右嵌入”（U+202A）

这是一个bug，还是一个特性

---

我的猜测是，这是一个有童车的功能

这个问题让我很困扰，一个确定性函数怎么可能对相同的输入给出两个不同的结果？经过一些测试，结果证明答案很简单

如果您在调试器中查看它，您将看到

@中的'D'字符‪D:\UserName\Desktop\cookie.png“

（首次使用十六进制函数）与

@“D:\UserName\Desktop\cookie.png”

（第二次使用）中的字符不同

您一定使用了其他类似于“D”的字符，可能是由于不需要的键盘快捷键，或者是由于干扰了Visual Studio字符编码

它看起来完全一样，但实际上它不是一个单独的字符9尝试观察toHex函数中的

c

变量

---

如果在第一个示例中更改为正常的“D”，它将正常工作。

包含RLO/LRO覆盖的文件名通常由恶意软件创建。例如。您可能有一个被感染的主机，或者.png的源代码被感染。

问题是字符串根本不是以字母

D

开头的，它看起来就是这样

该字符串似乎是在源文件中硬编码的

如果是这种情况，那么您已经从安全对话框粘贴了字符串。您不知道，粘贴的字符串以LRO字符开头。这是一个不可见的角色，它不显示任何空间，但告诉渲染器从左到右渲染角色，忽略通常的渲染

你只需要删除这个角色

---

为此，请将光标放在字符串中的D之后。使用Backspace或Delete to Left键

我知道这一点。但是如果你仔细观察并比较str和strRight，你会发现D是相同的D，问题是前面有一个文本流控制字符，你看不到，但是你只能通过删除D来删除它。在我看来，这是一个有缺陷的windows黑客程序，它应该使文件名在从右到左的系统上从左到右显示-这种黑客程序有一些令人讨厌的意外负面影响。尝试将第一个和第二个“D”复制到Watch in debugger中。尝试
“D”=”‪D“
（第一个“D”和第二个）。输出将为
false
。您正在谈论的文本流控制字符不在第一个“D”之前-它在该字符中；）@进退两难，或者，另一种方式-只需键入整个路径，而不是复制它并从“属性”窗口粘贴。你会发现它很好用。是的，在字符中，这正是重点。不，我懒得键入路径，但如果您从左到右标记路径，它会起作用，这是一个非常烦人的要求；）这是“死”字符，比如a:上的graf重音，或者n:ñ上的西班牙语波浪形。既然所讨论的“文件名”是windows驱动器号，而不是实际的文件名，那么你是说windows是恶意软件？然后我电脑上的所有文件都被感染了啊，有趣的是，这可能离事实并不远；）如果我只做一个屏幕截图，我也可以得到RLO/LRO，实际上是驱动器c&d上的任何文件，这是我仅有的可写驱动器。此外，这几乎不是一个受感染的主机，这是一个全新的机器（1周），我没有任何管理权。但有趣的是，exe恰好是一个植物园；）在这里猜测一下，但也许Win8有一些针对此类恶意软件的功能，您正在看到一种防御方式……只是想说，恶意软件的名称是Windows 8，带有阿拉伯语/希伯来语（或通常是从右到左的语言）i18n。那么，文件最初来自哪里？谁选择了文件名？哈哈，从右到左的语言颠倒了层次结构-这是非常有趣的一点。混合名字更有趣。注释前面的部分不是新的，但是对于其他有相同问题的人来说是可以的。