0x202A在文件名中:为什么?

我最近需要在varbinary图像上的SQL中执行isnull。
到目前为止(ab)正常。 我很快写了一个C#程序来从我的桌面读取no_image.png文件,并以hexstring的forms输出字节。

那个程序是这样开始的:

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”exception。

我发现问题是,当我右键单击文件,转到选项卡“安全”,并复制粘贴对象名称(开始标记在右侧 ,移动不正确的左侧),这种情况发生。

它只发生在Windows 8.1(也许是8)上,而不是Windows 7上。

202A

当我输出有问题的string时:

 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中查找20个2A时,它是[空间] + *

既然我看不到一个空间和一个明星,当我谷歌20 2A,我得到的第一件事是德国刑法第202a段http://dejure.org/gesetze/StGB/202a.html

但是,我认为这是一个不幸的巧合,实际上它是unicode控制字符“左alignmentembedded”(U + 202A) http://www.fileformat.info/info/unicode/char/202a/index。 HTM

这是一个错误,还是一个function?
我的猜测是,这是一个错误的function。

问题是这个字符串并不是以字母D开始的 – 它看起来就像它一样。

看起来这个字符串在您的源文件中是硬编码的。

如果是这种情况,那么你已经从安全对话框中粘贴了字符串。 你不知道,你粘贴的字符串从LRO字符开始。 这是一个看不见空间的无形字符,但是告诉渲染器从左到右渲染字符,忽略了通常的渲染。

你只需要删除字符。

为此,将光标放在字符串中的D之后。 使用Backspace或Delete to Left键<x]删除D 再次使用该键可以删除不可见的LRO字符。 再一次删除" 。现在重新输入"D

类似的问题可能发生在任何字符串来自 – 例如从用户输入,命令行,脚本文件等

注意:安全对话框显示以LRO字符开头的文件名,以确保字符按照从左到右的顺序显示,这对于确保在使用RTL字符时正确理解层次结构是必需的。 例如,在阿拉伯语中的文件名c:\folder\path\to\file可能是c:\folder\مسار/إلى/ملف 。 “gotcha”是在另一个方向阅读的阿拉伯语部分,所以根据谷歌翻译“路径”这个词是مسار,这是最右边的词,使它看起来是如果它是路径的最后一个元素,事实上它是紧接在“c:\ folder \”之后的元素。

由于安全对象路径的层次结构与RTL文本布局规则相冲突,因此安全对话框始终以LTR模式显示RTL文本。 这意味着在安全选项卡上的阿拉伯语单词将被打乱(字母顺序错误)。 (想象一下,如果它说“elif ot htap”)。 所以意义是可辨别的,但从安全角度来看,安全语义是保留的。

包含RLO / LRO覆盖的文件名通常由恶意软件创建。 例如。 “exe”反向读取“恶意软件” 。 您可能有受感染的主机,或者.png的来源受到感染。

这个问题困扰了我很多,一个确定性的函数怎么可能给同样的输入提供两个不同的结果呢? 经过一些测试,结果是答案很简单。

如果你在调试器中查看它,你会发现在你的@"‪D:\UserName\Desktop\cookie.png" (首次使用Hex函数)中的'D'字符不是在@"D:\UserName\Desktop\cookie.png" (第二次使用)。

您必须使用其他“D”字符,可能是通过不需要的键盘快捷方式或通过与您的Visual Studio字符编码搞乱。

它看起来完全一样,但事实上它不是一个单一的char 9try来观察toHex函数中的c变量。

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