asp.net mvc textarea vs jQuery中换行符的字符数

Question

I'm working on a ASP.NET MVC web application. I have a textarea in the view and it's binded to a model which has maximum length of 1000.

//Html:
@Html.TextAreaFor(model => model.Description, 12, 50, new { @class = "form-control", @placeholder = "Mandatory" })

//Model class:
[Required]
[DisplayName("Event Description")]
[MaxLength(1000, ErrorMessage = "Maximum {1} characters.")]
public string Description { get; set; }

I'm also using jQuery to display a message for the user so that they know how many characters are left to enter:

    $('#Description').keyup(function () {
        var maxlen = 1000;
        var count = $(this).val().length;
        var charLeft = maxlen - count;
        var string = charLeft + " chracters left"
        if (count > maxlen) {
            this.value = this.value.substring(0, maxlen);
        }
        else {
            $("#descriptionCharCount").text(string);
        }
    });

I found that when there's a new line entered, ASP.NET will insert 2 spaces and therefore increase the character count by 2. But jQuery only increase by 1. This resulting a mismatch. How do I solve this problem?

Answer 1

Why it happens: Windows uses two characters ( \\r\\n ), to represent a new line, whereas some browsers only use one of these characters ( \\n ). So when the model binder converts the input into a string, you actually have a string that uses two characters.

There are a number of ways to try to address this, with varying levels of "correctness." Here are some posts that address the issue:

• http://blog.sarathonline.com/2009/09/javascript-maxlength-for-textarea-with.html
• http://kenegozi.com/blog/2010/04/19/newlines-in-textarea-are-treated-differently-on-different-browsers/
• jQuery validate textarea maxlength bug

It seems to me that the most correct way is to take a two-pronged approach:

1. Write your length-checking algorithm in a way that ignores the \\r characters, and
2. Use a model binder that removes \\r characters from strings sent to the server, prior to server-side validation.

However, bear in mind that this might have a few unexpected results. For example, if users download a file based on the input they've saved, and then open it in a program like Notepad (which only recognizes \\r\\n combos as newlines) they wouldn't see the line breaks.