#1257 Bug when loading sql files via double click, messes characters such as é or ã

[Anonymous]

Originally created by: Antoni...@gmail.com

What exact steps will reproduce the problem?
1. Open an sql file with data that contains characters such as é or ã by
double cling on them and having heidisql open them

What was the expected output?
This should have been in the editor
(10, '1225711391', 15059, '', 'Bom dia, gostaria de apresentar a minha
candidatura para os serviços na Vossa empresa. Contactos: ', '1', 0, '', 0, 0),

What happened instead?
This is what appears in the HeidiSQL editor

(10, '1225711391', 15059, '', 'Bom dia, gostaria de apresentar a minha
candidatura para os serviços na Vossa empresa. Contactos: ', '1', 0, '',
0, 0),

This does not happen if I open the editor and past the sql code

Suggested fix (optional)?

Make the correct characters appear

Version used?
HeidiSQL revision: 2517 (this has been showing up in previous versions)
MySQL Server version: 5.0.67-community-nt
Operating system: Windows XP Pro

[Anonymous]

Originally posted by: a...@anse.de

Probably the file doesn't have the correct BOM marker so HeidiSQL detects it with
Latin1 charset. How did you create it? Could you attach that file here please?

Status: NeedInfo

[Anonymous]

Originally posted by: Antoni...@gmail.com

I can't attach the file sorry. It has user data from my site.
The file was generated by phpMyAdmin via the export option

[Anonymous]

Originally posted by: rosenfie...@gmail.com

I think that:
- the encoding autodetect code should be removed
- new file types should be added to the load dialog:
   * "ANSI or Unicode text file"
   * "UTF-8 text file without BOM"
- the default should be "ANSI or Unicode text file"
- the default should not change when the user changes selection
- the default should do the following:
   - load as current ANSI codepage when there is no BOM
   - load as UTF-xx when there is a BOM

That way, when users do something that is impossible to handle correctly in an
automated manner (such as trying to load a BOM-less UTF-8 file, which is probably the
case here), the situation can be resolved by the user manually selecting "UTF-8 text
file without BOM".

(Or by using something else than phpmyadmin to generate sql exports ;-).)