String.Formatの危険性(改) その5です。「 [VB.NET] 正規表現のエスケープ 」からの続きです。
　今回が最終回です。

　前回を最終回にしようと思っていたのですが、「プログラマのための文字コード技術入門 (ISBN-13:978-4774141640)」を先日購入しまして、眺めていると興味深いことが書かれていたのでメモ。

　javaでは、unicodeのエスケープは文字列ではなく、まさに文字(?)らしく、ソースコードに対しても効いてくるらしいです。従って以下のコードはコンパイルできません。

java

public class Main {
    public static void main(String[] args) {
        System.out.println("aaaau000abbbb");
    }
}

　なんでかというと、コンパイラ(?)は上記のソースコードは以下のように見えるから。

java

public class Main {
    public static void main(String[] args) {
        System.out.println("aaaa      ←文字列の途中で改行されているように見える
bbbb");
    }
}

　ちなみにC#で、同様のコードを書いてみたところ、これはコンパイルエラーとなりませんでした。

C#

class Program
{
    static void Main(string[] args)
    {
        System. Console.WriteLine("aaaau000abbbb");
    }
}

　これを逆手にとって、javaでは以下のようなコードが書ける模様。

java

public class Main {
    public static void main(String[] args) {
        String u0061 = "aaaa";
        System.out.println(a);
    }
}

　…なんと面妖な。
　てことは、C#では同じ事は出来ないんだな？と思って実験。

C#

class Program
{
    static void Main(string[] args)
    {
        string u0061 = "aaaa";
        System.Console.WriteLine(a);
    }
}

　先生！コンパイルエラーになりません。出来る模様です…最早何がなんだか（笑
　このあたり、XSS系のプロフェッショナルが詳しいんだろうなあ。とか。

　そんなわけで、たかがエスケープですが、奥が深うございました。
　奥深く考える機会をいただいた、よねけんさんに感謝したいと思います。

　# しかし入り口のさわりで、まだまだ奥があるのでしょうが… --;