Search jQuery

jQuery Forum

Developing jQuery Core

delijah

[domelem].value.length returns different value than $([domelem]).val().length

Not a problem

Need more info
Not a problem
Temporary fix
Analyzing
Working on it
Solved

in Developing jQuery Core • 10 years ago

Hello

I'm playing around with reading the value.length of textarea's. Everything works fine, as long you're not using linebreaks.. and there it starts..

First of all, my environment details

OS:       Windows XP SP3
Browser:   IE 7.0.5730.13 (standards compliant rendering mode), Firefox 3.5.5
Doctype:   XHTML-Strict

Some facts

OS:

Windows is using by default 2 bytes for a linebreak
Unix is using by default 1 byte for a linebreak
Mac is using by default 1 byte for a linebreak

http://en.wikipedia.org/wiki/Newline

JavaScript:

As far as I know JavaScript is using only 1 byte for a linebreak (\n). Doesn't matter if it's running on a Windows/Unix/Mac OS.

HTTP/1.1 protocol:

HTTP/1.1 uses 2 bytes for a linebreak, if I understand correctly..

"HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body..."

http://www.rfc-editor.org/rfc/rfc2616.txt

Tests

I have a form and within, there is a textarea element. I write the following text into it (without the start and end lines):

-- start
a
b
c
-- end

The following happens..

$textarea = $("textarea");
alert($textarea.val().length); // 1. Will alert 5
alert($textarea[0].value.length); // 2. Will alert 7

After my "investigations" I realized, this behavior is caused by the difference between how many bytes are used for a linebreak.

On a linux system with any browser the 2. statement will also return 5 (because unix uses only 1 byte for a linebreak).
But if I submit the form to the server, and check the length of the data of the textarea, it will tell me the string is 7 chars long (because http/1.1 uses 2 bytes per linebreak I guess).

Unfortunately I was not able to test it on a Mac.

Conclusion

I think it would be nice if the length property would return the correct value.. especially if you want to make some validation on a form/textarea.

Since http/1.1 protocol always converts 1 byte linebreaks to 2 bytes, we could assume that the webserver is always receiving 2 bytes for a linebreak. So also 2 bytes would be written to the database ( I hope I'm not telling bullshit here! :)

My solution at the moment is the following function:

if (String.prototype.realLength == undefined) {
String.prototype.realLength = function() {
var regex
if (regexp.test(this)) {
do { matchCount++; } while (regexp.exec(this));
return this.replace(/\n|\r/g, "").length + matchCount * 2;
}
return this.length;
};
}

Maybe there are better/different solutions, or maybe I made a mistake during my "investigations".

Please let me know..

Cheers, delijah

Replies(11)

jeresig

Re: [domelem].value.length returns different value than $([domelem]).val().length

10 years ago

I'm a bit confused - wouldn't you want it to always return the same value across platforms that way you could actually do validation? As it stands you'll get different answers on each platform making it challenging to do validation (as you put it).

delijah

Betreff: [domelem].value.length returns different value than $([domelem]).val().length

10 years ago

Yes exactly, the goal is to have the same value length across all platforms. But at the moment it's not like that.

Windows:

$textarea = $("textarea");
alert($textarea.val().length); // 1. Will alert 5
alert($textarea[0].value.length); // 2. Will alert 7

Linux (tested on ubuntu):

$textarea = $("textarea");
alert($textarea.val().length); // 1. Will alert 5
alert($textarea[0].value.length); // 2. Will alert 5

With the method "realLength" you will get always the same value (7 for the above example). The method "realLength" counts 2 bytes for every linebreak (doesn't matter on which platform or in witch browser u are browsing).

Why do i propose to count 2 bytes per linebreak on every platform and not 1?
Well because my theory says, that the webserver will always receive 2 bytes per linebreak, because HTTP/1.1 converts every linebreak to 2 bytes (even if the client sends 1 byte for linebreaks).

Cheers, Raffael

dave.meth..

Re: Betreff: [domelem].value.length returns different value than $([domelem]).val().length

10 years ago

If jQuery is returning a consistent value across browsers and platforms, it sounds like it's doing the right thing. The inconsistent cases shown above happen when jQuery methods aren't used.

What's the bigger issue with the discrepancy in length here? How does it affect your code?

delijah

Betreff: [domelem].value.length returns different value than $([domelem]).val().length

10 years ago

Yes, i agree on that. jQuery has the advantage that it always returns a consistent value across browsers and platforms.

But since the webservers always get a different value (jQuery gets a length of 5 - in the example shown above - and the webserver/server side script gets a length of 7), when they check the length of this value, it would make sense to adjust that in jQuery (in my case).

For example:
- I have a textarea with a maxlength of 10 chars
- I have a varchar field in a database width a length of 10 chars

Now i want to check the maxlength already in the browser, to make sure, that the server side script is gonna save exactly the value in the database, the user sees in the webbrowser.

If a user would enter the following:

-- start
a
b
c
d
e
-- end

jQuery would tell me this value has a length of 9 chars, but the server side script/database will tell me this value has a length of 13 chars..

jeresig

Re: Betreff: [domelem].value.length returns different value than $([domelem]).val().length

10 years ago

Sounds like this is a server-side issue, then - you should probably be normalizing the endlines for your input.

delijah

Betreff: [domelem].value.length returns different value than $([domelem]).val().length

10 years ago

well i could normalize the input in my case, but i think a lot of other people have to deal with the same situation, becuase the server side script is always getting 2 bytes per linebreak and not 1.

i have tested it within the following scenarios:

client:   windows xp, firefox
server:   windows 2008 64bit, iis7, coldfusion9

client:   ubuntu linux, firefox/links 2
server: ubuntu linux, apache2, php5x

all of the server-side scripts received 2 bytes per linebreak.

so for me it doesn't make sense then to count 1 byte per linebreak on the client-side.

well, it's up to you. maybe i stick to much to my example..

by the way, thanks for your recent responses.

joshjordan

Re: [domelem].value.length returns different value than $([domelem]).val().length

9 years ago

It's great that jQuery is normalizing the endlines, but I think his point is that jQuery is normalizing the endlines the wrong way. It seems that on all platforms, the browser converts an Enter keypress in a textarea to the two-byte sequence "\r\n" when submitting the form. However, jQuery's val() method converts an Enter keypress in a textarea to the one-byte sequence "\n". We could either change every server to convert "\r\n" to "\n", or jQuery could simply return the correct value in the first place.

MikeBeale

Re: [domelem].value.length returns different value than $([domelem]).val().length

9 years ago

I have to agree with joshjordan above, jQuery is normalizing the end of lines but in the wrong way.

I'm inserting into an MS SQL database using ASP or ASP.Net.
Got a textarea I'm trying to limit to 500 characters, and a table varchar field of 500 length.

With line breaks in the textarea jQuery incorrectly counts the line breaks as 1 character, and if the textbox is length 500 accoring to jQuery it will get truncated on the insert as the line breaks are now 2 characters.

I can't test on any other platforms, apart from testing with IE8 or Firefox 3.6 on Windows XP.
As everything is on windows I'd expect line breads to be 2 characters.

I did notice that document.getElementById("mytextarea").value.length reports differently with line breaks on IE8 and Firefox 3.6, so jQuery is normalizing, just incorrectly.

I've implemented a function as below (I've used your function name delijah as I couldn't think of a better name!)

(function($){
$.fn.realLength = function() {
if ($(this).length == 1) {
return $(this).val().replace(/\n|\r/ig,' ').length;
} else {
return null;
}
};
})(jQuery);

MikeBeale

Re: [domelem].value.length returns different value than $([domelem]).val().length

9 years ago

Okay, now caused another problem.

Using my function above correctly reports the length of the textarea with line breaks.

Problem I now have is that when the length is over say 500, I'm doing a substr to the max length:
textBox.val(textBox.val().substr(0,maxLen));
but .val() or .substr is obviously using 1 char for the line feeds, so the result of the substr is greater than 500 characters.

What I've now done is to count the line feeds before doing the substr:
var lineFeeds = textBox.val().split(/\n/).length-1;
textBox.val(textBox.val().substr(0,maxLen-lineFeeds));

BUT, IE doesn't split if there is a blank line, where as Firefox and Chrome do, so still working on that.

Mike

dave.meth..

Re: [domelem].value.length returns different value than $([domelem]).val().length

9 years ago

> As everything is on windows I'd expect line brea[k]s to be 2 characters.

Unfortunately that is not true. Firefox, Chrome, and Safari use \n for line breaks in text inputs on Windows; only Opera and IE use \r\n on Windows. On all other platforms it is just \n, a single character.

One relevant change made in 1.5 was to make sure that .serialize() always used \r\n when serializing the form, since the W3C says that it must be that way. If you need to stay under 500 characters, one way to do it would be to have your server code convert the two-character sequence to a single character before saving it.

As an aside, if you are using varchar and not nvarchar then you may have issues with character conversions for text that isn't using the same code page as the server.

MikeBeale

Re: [domelem].value.length returns different value than $([domelem]).val().length

9 years ago

Hi Dave,

Problem is that the server uses 2 characters for line feeds, so the length can too long in Firefox etc.
So in IE the check client side is correct, and won't get trimmed, but in Firefox it can be too long and get's truncated on the server, so the check surely has to be done client side otherwise text that the user has inputted may get truncated on the server.

Anyway, I've fixed my little code snippet above, this works in IE & Firefox:
var lineFeeds = textBox.val().match(/[^\n]*\n[^\n]*/gi).length;
textBox.val(textBox.val().substr(0,maxLen-lineFeeds));

All seems to be working correctly now.

Top Reply

Response title

Attachments

jQuery Forum

[domelem].value.length returns different value than $([domelem]).val().length

Not a problem

Replies(11)

Re: [domelem].value.length returns different value than $([domelem]).val().length

Betreff: [domelem].value.length returns different value than $([domelem]).val().length

Re: Betreff: [domelem].value.length returns different value than $([domelem]).val().length

Betreff: [domelem].value.length returns different value than $([domelem]).val().length

Re: Betreff: [domelem].value.length returns different value than $([domelem]).val().length

Betreff: [domelem].value.length returns different value than $([domelem]).val().length

Re: [domelem].value.length returns different value than $([domelem]).val().length

Re: [domelem].value.length returns different value than $([domelem]).val().length

Re: [domelem].value.length returns different value than $([domelem]).val().length

Re: [domelem].value.length returns different value than $([domelem]).val().length

Re: [domelem].value.length returns different value than $([domelem]).val().length

Statistics

Tags

Actions