The overarching issue is locales (in some locales, commas are treated as decimal points and semicolons are the field separators). Excel's general backdoor for the delimiter is the sep= pragma.

We'd accept a PR that adds an override. The change would be in bits/40_harb.js:

		if(str.slice(0,4) == "sep=") {
			// If the line ends in \r\n
			if(str.charCodeAt(5) == 13 && str.charCodeAt(6) == 10 ) {
				sep = str.charAt(4); str = str.slice(7);
			}
			// If line ends in \r OR \n
			else if(str.charCodeAt(5) == 13 || str.charCodeAt(5) == 10 ) {
				sep = str.charAt(4); str = str.slice(6);
			}
			else sep = guess_sep(str.slice(0,1024));
		}
+		else if(opts && opts.FS) sep = opts.FS;
		else sep = guess_sep(str.slice(0,1024));

and the end code would be

X.read(e.target.result, { type: 'string', FS: ";" })

@SheetJSDev Can I take this issue?

The overarching issue is locales (in some locales, commas are treated as decimal points and semicolons are the field separators). Excel's general backdoor for the delimiter is the sep= pragma.

We'd accept a PR that adds an override. The change would be in bits/40_harb.js:

		if(str.slice(0,4) == "sep=") {
			// If the line ends in \r\n
			if(str.charCodeAt(5) == 13 && str.charCodeAt(6) == 10 ) {
				sep = str.charAt(4); str = str.slice(7);
			}
			// If line ends in \r OR \n
			else if(str.charCodeAt(5) == 13 || str.charCodeAt(5) == 10 ) {
				sep = str.charAt(4); str = str.slice(6);
			}
			else sep = guess_sep(str.slice(0,1024));
		}
+		else if(opts && opts.FS) sep = opts.FS;
		else sep = guess_sep(str.slice(0,1024));

and the end code would be

X.read(e.target.result, { type: 'string', FS: ";" })

We have done exactly this workaround on the code side (reading the first line and finding out the separator). I thought it could be done automatically.

The current behavior is consistent with Excel.

Consider the original sample file:

A;B;C;D
1,1;2,2;3,3;4,1
1,1;2,2;3,3;4,1
1,1;2,2;3,3;4,1

In the English (United States) regional setting, Excel will parse as if the field separator (Windows calls this "List separator") is the comma character:

If you are using a regional setting with ";" as the list separator and "," as the decimal symbol, then you will get the parse you expect.

In windows 7 these settings can be found in "Control Panel" > "Clock, Language, and Region" > "Region and Language" > "Additional Settings". en_US has the following settings:

Note: Excel's backdoor for controlling the list separator is the aforementioned sep= pragma. If you do specify it, Excel will use the separator but it won't change the decimal separator:

#malek``