MySQL Bugs: #74914: MySQL WorkBench 6.2.3 gives error with files UTF-8 (works fine UTF-8 w /oBOM)

Bug #74914	MySQL WorkBench 6.2.3 gives error with files UTF-8 (works fine UTF-8 w /oBOM)
Submitted:	18 Nov 2014 15:01	Modified:	20 Nov 2014 22:38
Reporter:	Marco Del Corto	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S3 (Non-critical)
Version:	6.2.3	OS:	Windows (8.1)
Assigned to:		CPU Architecture:	Any
Tags:	MySQL WorkBench 6.2.3, sql editor, UTF-8 w / o BOM

Description:
The problem (Error Code 1064 - You have an error in your SQL syntax) occurs if I execute sql script from a file that has Encoding "UTF-8" (works fine with UTF-8 w / o BOM).
I verified with Notepad++ the encoding of sql file executed in Workbench Editor (namely Notepad++ menu: Edit/EOL Conversion/ and menu: Encoding/ ) and I saw the following behaviour:
a) the sql file that worked well in previous release (6.1.7) of WorkBench but not in new release (6.2.3) has the following attributes:
- EOL Conversion: Unix
- Encoding: UTF-8
b) to solve the problem in the new release (6.2.3) must be set, for the sql file, the following attributes:
- EOL Conversion: Unix
- Encoding: UTF-8 w/o BOM
note: these attributes (UTF-8 w/o BOM) are the same as those of when the Editor Workbench saves the file sql.
Questions: why is there this difference between 6.1.7 and 6.2.3 release (there are other ways to avoid the error, eg with configuration parameters)?
Thanks

How to repeat:
To repeat the error execute in SQL Editor of MySQL Workbench a file with Encoding UTF-8 w/o BOM.

Suggested fix:
If possible to make customizable the management of encoding (UTF-8, UTF-8 w/o BOM, ...) or, better, handle automatically the various encoding types.

Please provide a test file to repeat the issue. Thanks.

Sample File with explanatory screenshot

Attachment: sample_file.zip (application/zip, text), 131.30 KiB.

How to repeat (errata corrige)
To repeat the error execute in SQL Editor of MySQL Workbench a file with Encoding UTF-8.

Thank you for the feedback.

This issue affects us in the latest Workbench 6.3.8.
We are trying to run a script with a create Table statement in it, I pasted the script at the end.

With Windows style end of line marking (CR LF) we receive a syntax error 1064 with a script IF you open it in the Editor and then attempt to Execute (All or Selection).

Error Code: 1064. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CREATE TABLE IF NOT EXISTS profile(' at line 1

Script executes happily with the 'Execute (All or Selection)'

- if the file has Unix style coding with LF only as line ending.

For end-of-line CR LF, the script can be executed with the 'Execute (All or Selection)':

- if you HIGHLIGHT ALL of the script but only by dragging TOP-TO-BOTTOM! 
(Ctr-A or bottom-to-top dragging does highlight, but still provides failure when attempting to Execute the Execute (All or Selection))

- if you do not open the script in the editor but instead execute the 
File/Run SQL Script/ [ name of the script] 

Steps to failure:

Open the SQL script containing (CR LF) in the Workbench Editor:
File/Open SQL Script -> [select file]
and attempt to run it by 
pressing the lightning symbol or 
Query/'Execute (All or Selection)' or 
Qtrl-Shift-Enter

message:
Error Code: 1064. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CREATE TABLE IF NOT EXISTS profile(' at line 1

script:
CREATE TABLE IF NOT EXISTS profile(
  ID BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  NAME VARCHAR(255)  NOT NULL,
  TRANSCODER_TYPE INT(10) UNSIGNED NOT NULL,
  PRIMARY KEY (ID),
  UNIQUE INDEX NAME (NAME),
  INDEX PROFILE_IDX01 (ID)
)
ENGINE = INNODB
AUTO_INCREMENT = 14
AVG_ROW_LENGTH = 1260
CHARACTER SET utf8
COLLATE utf8_general_ci;

To add to the previous comment I have confirmed with a selection of the files, that the SQL script files which have the "EF BB BF" BOM pre-amble in the octal dump are the ones that fail unless you highlight text visible in the editor starting from the first visible character.

Presumably, Ctrl-A or start highlighting from the end selects the BOM sequence too and the Execution fails.