文件名中的0x202A：为什么？ [英] 0x202A in filename: Why?

问题描述

我最近需要在varbinary映像上用SQL进行isull。

到目前为止（正常）。
我很快编写了一个C＃程序，从我的桌面读取文件no_image.png，并将字节输出为十六进制字符串。

I recently needed to do a isnull in SQL on a varbinary image.
So far so (ab)normal. I very quickly wrote a C# program to read in the file no_image.png from my desktop, and output the bytes as hex string.

该程序如下所示：

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异常。

And as I had used readallbytes countless times before, I figured no big deal.
To my surprise, I got a "NotSupported" exception on ReadAllBytes.

我发现问题是，当我右键单击该文件时，转到安全性选项卡，然后复制粘贴对象名称（在右，然后向左错误地移动），就会发生这种情况。

I found that the problem was that when I right click on the file, go to tab "Security", and copy-paste the object-name (start marking at the right and move inaccurately to the left), this happens.

并且它仅在Windows 8.1（可能是8）上发生，而不是在Windows 7上发生。

And it happens only on Windows 8.1 (and perhaps 8), but not on Windows 7.

< img src = https://i.stack.imgur.com/ulwNn.png alt = 202A>

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

When I output the string in question:

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)

20 2A in ascii，它是[空格] + *

First thing, when I lookup 20 2A in ascii, it's [space] + *

由于我既看不到空间，也不看星星，所以当我用Google 20 2A搜索时，第一件事是德国刑法
的第202a段 http://dejure.org/gesetze/ StGB / 202a.html

Since I don't see neither a space nor a star, when I google 20 2A, the first thing I get is paragraph 202a of the german penal code http://dejure.org/gesetze/StGB/202a.html

但是我想这是一个不幸的巧合，它实际上是Unicode控制字符'LEFT-TO-RIGHT-EMBEDDING'（ U + 202A）
http：//www.fileformat。 info / info / unicode / char / 202a / index.htm

But I suppose that is rather an unfortunate coincidence and it is actually the unicode control character 'LEFT-TO-RIGHT EMBEDDING' (U+202A) http://www.fileformat.info/info/unicode/char/202a/index.htm

是错误还是功能？

我的猜测是，这是一个越野车功能。

Is that a bug, or is that a feature ?
My guess is, it's a buggy feature.

推荐答案

问题是字符串不是以字母 D

The issue is that the string does not begin with a letter D at all - it just looks like it does.

该字符串似乎在源文件中进行了硬编码。

It appears that the string is hard-coded in your source file.

如果是这种情况，那么您已经从安全性对话框中粘贴了字符串。未知的是，您粘贴的字符串以LRO字符开头。这是一个看不见的字符，没有空格，但是告诉渲染器从左到右渲染字符，而忽略了通常的渲染。

If that's the case, then you have pasted the string from the security dialog. Unbeknownst to you, the string you pasted begins with the LRO character. This is an invisible character which tales no space, but tells the renderer to render characters from left-to-right, ignoring the usual rendering.

您只需要删除

要执行此操作，请将光标置于字符串中D之后。使用Backspace或Delete to Left键< x] 删除 D 。再次使用该键删除不可见的 LRO 字符。再删除一次 。现在重新键入 和 D 。

To do this, position the cursor AFTER the D in the string. Use the Backspace or Delete to Left key <x] to delete the D. Use the key again to delete the invisible LRO character. One more time to delete the ". Now retype the " and the D.

无论字符串来自何处，都可能发生类似的问题-例如来自用户输入，命令行，脚本文件等。

A similar problem could occur wherever the string came from - e.g. from user input, command line, script file etc.

注意：安全对话框显示以LRO字符开头的文件名，以确保字符按从左到右的顺序显示，这是确保使用RTL字符时正确理解层次结构所必需的。例如阿拉伯文文件名 c：\folder\path\to\file 可能是 c：\folder\مسار/إلى/ ملف。 gotcha是从另一个方向读取的阿拉伯语部分，因此，根据Google翻译， path一词是مسار，它是最右词，使得它似乎是最后一个元素

Note: The security dialog shows the filename beginning with the LRO character to ensure that characters are displayed in the left-to-right order, which is necessary to ensure that the hierarchy is correctly understood when using RTL characters. e.g. a filename c:\folder\path\to\file in Arabic might be c:\folder\مسار/إلى/ملف. The "gotcha" is the Arabic parts read in the other direction so the word "path" according to google translate is مسار, and that is the rightmost word, making it appear is if it was the last element of the path, when in fact it is the element immediately after "c:\folder\".

因为安全对象路径具有与之冲突的层次结构，所以实际上它是紧接在 c：\folder\之后的元素。

Because security object paths have an hierarchy which is in conflict with the RTL text layout rules, the security dialog always displays RTL text in LTR mode. That means that the Arabic words will be mangled (letters in wrong order) on the security tab. (Imagine it as if it said "elif ot htap"). So the meaning is just about discernable, but from the point of view of security, the security semantics are preserved.

这篇关于文件名中的0x202A：为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！