There seems to be an issue during compile with at least one escape sequence

[mcgear]

I have already created a pull request for you to include that has unit test setup to showcase the error.

https://github.com/rexm/Handlebars.Net/pull/348

Essentially the issue is that when using json like the following: {"Description":"**\\*.{{Thing.Name}}"}

After running the template through compile: `var json = new TestJSONObject() { Name = "Thing - {{Thing.Name}}", Description = "*\.{{Thing.Name}}", Test = new TestJSONObject() { Test = new TestJSONObject() { Name = "\"{{Thing.Name}}\"" } } };

        var source = JsonConvert.SerializeObject(json);

        var template = Handlebars.Compile(source);

        var data = new
        {
            Thing = new
            {
                Name = "Handlebars.Net"
            }
        };

        var result = template(data);`

The result comes out with: {"Description":"**\*.Handlebars.Net"}

And then if i try to parse that json back into object: var resultJson = JsonConvert.DeserializeObject<TestJSONObject>(result);

An error is thrown because '*' is not a valid escape character: 'Bad JSON escape sequence: \*. Path 'Description', line 1, position 20.'

[oformaniuk]

It looks like the problem is related to the way escape characters are processed (see Tokenizer). It seems like non-Handlebars issue. In order to preserve the escape character you need to also escape it:

var json = new TestJSONObject()
{
    Description = "**\\\\*.{{Thing.Name}}",
};

[mcgear]

Thanks, that is how i was approaching it now, but was trying to avoid that as well as our solutions faces customers, and that seemed an odd requirement to pass along to them.

Thanks for the help

[mcgear]

Do you know if there is a reason it is processing that escape sequence but non of the others? I mean i see the code, but why only handle that double escape sequence and nothing else?

[mcgear]

I'm wondering what the implications of removing it in my own fork would be? Which is why i'm wondering the "why" is it there in the first place.

Thanks for any help.

[mcgear]

I got some time to take a look at this today, and seem to have found a fix that allows all old situations to pass, while also supporting the need for multiple layers of \ sequences.

I updated my original pull request with the fix instead of just the new tests. We have been able to create our own build against my fork with this fix, so have a workaround for ourselves.