从文本文件读取Javascript

Question

Okay, this may be hard to explain.
The Passwords don't work the usernames do.
I am reading from a text file.

"username,password" is the structure for the below is the text file

John,BOL12345
Mary2,BOL77777
Anna,BOL54321
test,BOL12345

The top 3 do not work alone i only need the top 3
but once i add the "test,BOL12345"
the password BOL12345 does work
but without the "test,BOL12345" The password "BOL12345" does not work or any of the other ones
I am doing this all in javascript below will be the code snippet.. please ask any questions as i do not understand why this happens.

The JavaScript Below
The "lines" = the text file above

    lines = x.responseText.split("\n");
    for (i=0; i < lines.length; i++)
    {
        test1 = lines[i].split(",")
        username.push(test1[0]);
        password.push(test1[1]);

    }
    var tempUsername = document.getElementById('username').value;
    var tempPassword = document.getElementById('password').value;
    var arraycontainsusername = (username.indexOf(tempUsername) > -1);
    var arraycontainspassword = (password.indexOf(tempPassword) > -1);
    alert(password);
    if (arraycontainsusername && arraycontainspassword) {
        window.location.href = "listing.htm";
    };

Answer 1

Educated guess: your file is using \\r\\n . since you're splitting by \\n the \\r is left in and corrupts each string. try splitting by \\r\\n and see what happens. That would explain why adding the last line would work, since there's no newline at the end there won't be a trailing character to mess up the indexOf search.

different operating systems handle text files differently. Windows uses CRLF (Carriage Return Line Feed) to jump to the next line, while *NIX variants use LF. old MacOS versions use CR. Your code was assuming the file came from a *NIX environment, where LF (or \\n ) is the norm, when it came from a windows environment, where CRLF (or \\r\\n ) is the norm (not accurate since you can make text files with LF in windows and with CRLF in *NIX, buy you get the picture).

To handle all cases correctly, I'd recommend normalizing the string before working on it:

x.responseText.replace(/\\r\\n|\\r(?!\\n)/g, '\\n').split('\\n');

that seemingly chinese string in the middle is actually a regular expression that matches either \\r\\n or \\r (but only when \\r isn't followed by \\n). this way you can replace all your CRLFs and CRs to LF and handle text coming from any environment.

you can simplify that regex because of the order of the tokens, to /\\r\\n|\\r/ , but I'm leaving it in because it illustrates a neat concept (lookaheads - that bit (?!\\n) says if and only if not immediately followed by a \\n ). With that said /\\r\\n|\\r/ will perform better, especially when handling large files