File Encoding And BOM Fixer
Every CSV or log an expert or script writes out lands in one of two shapes: plain ANSI, one byte per character, or UTF-16LE, two bytes per character, usually with a leading FF FE mark. Most software copes with either. The software that does not - an older accounting import, a legacy report template, a script written to expect exactly one of the two - fails quietly or garbles the first few characters, and there is no menu anywhere in the terminal to fix it. The obvious approach is to let FileOpen's own FILE_ANSI and FILE_UNICODE modes do the conversion: open the source in one, write the destination in the other. That was tried and rejected. Those flags decide on their own whether to emit a byte order mark, and the decision is not documented and not guaranteed stable across builds. A script whose entire purpose is controlling the BOM cannot depend on a mode that controls it invisibly. So this script works one layer down, in FILE_BIN, reading and writing raw bytes. The BOM is detected by literally checking the first two or three bytes. The body is decoded and re-encoded by hand: ANSI through CharArrayToString and StringToCharArray against the terminal's codepage, UTF-16LE by unpacking or packing two bytes per character directly, since an MQL string already stores UTF-16 internally and only needs the bytes placed in the right order. Nothing is guessed from a library's internal behaviour. A UTF-8 or UTF-16BE source is refused rather than approximated. Converting either correctly needs a real Unicode transcoder, not two dozen lines in a sandbox utility, and a wrong guess would corrupt exactly the file the user was trying to fix. Re-export the source as ANSI or UTF-16LE first. Notes and limitations - Only ANSI and UTF-16LE are supported, in both directions. UTF-8 and UTF-16BE sources are refused outright, with the byte order mark that was found named in the alert. - Conversion uses the terminal's own ANSI codepage (CP_ACP). Characters that do not exist in that codepage are lost the same way they would be in any ANSI-only tool - this script does not add support the target encoding itself lacks. - The file must sit under the platform's own Files folder (MQL4\Files or MQL5\Files). Files outside the sandbox are not reachable without the common-folder flag, which this script does not use. - Very large files are read fully into memory as a byte array before any conversion happens; there is no streaming pass.
Script · MT4 · v1.0 · Free
About File Encoding And BOM Fixer
File Encoding And BOM Fixer is a script for MetaTrader 4. It can alert you with a pop-up, sound, email or push message. It has 5 settings, such as Input file, Output file and Source encoding. MQL source code included.
Files in the download: FileEncodingBomFixer.ex4, FileEncodingBomFixer.mq4, FileEncodingBomFixer.txt.
Settings
| Setting | Default | What it does |
|---|---|---|
| Input file | Input file, relative to MQL4\Files | |
| Output file | Output file (blank = auto name) | |
| Source encoding | SRC_AUTO | Source encoding |
| Target encoding | TGT_ANSI | Target encoding |
| Add bom | false | Add a byte order mark to the output |
How to install
- Download the ZIP from your PolyMaria library and unzip it.
- In MetaTrader 4 open File → Open Data Folder, then go to MQL4 → Scripts.
- Copy the .mq4 file(s) there. Put any .mqh files in MQL4 → Include.
- Open the .mq4 file in MetaEditor and press Compile (F7) if MetaTrader does not show it.
- Drag the script onto a chart to run it once.
Tags: Alerts · MT4 Script · MQL4 Source Code