Kodowanie plików MQL5: UTF-8 kontra UTF-16
W skrócie: pliki .mq5 i .mqh bywają zapisane w UTF-16 (dwa bajty na znak), szczególnie jeśli przyszły
z pobranego kodu albo ze starej wersji edytora. Kompilator je czyta bez problemu, ale git traktuje taki plik jak
binarny, diff i przegląd zmian nie działają, a wyszukiwanie tekstu pomija plik. Trzymam kod w UTF-8 i pilnuję
tego hookiem przy commicie.
Objaw
Pierwszy sygnał to komunikat gita, że plik jest binarny, albo diff, który zamiast zmienionych linii pokazuje
cały plik. Drugi: grep nie znajduje tekstu, który wyraźnie jest w pliku. Powód jest ten sam. W UTF-16 każdy znak
ma dwa bajty, więc napis Risk zapisany jest jako R\0i\0s\0k\0, a zwykłe wyszukiwanie bajtowe go nie widzi.
Plik zwykle zaczyna się też od znacznika BOM (dwa bajty na początku).
Dlaczego to ma znaczenie dla botów
- Przegląd zmian (diff) jest podstawą kontroli wersji. Nieczytelny diff oznacza, że zmiany wchodzą “na ślepo”.
- Narzędzia, które szukają po kodzie (a także asystent AI czytający repo), mogą pominąć albo błędnie odczytać plik.
- Połączenie dwóch gałęzi na pliku binarnym kończy się konfliktem, którego nie da się rozwiązać linia po linii.
- Polskie znaki w komentarzach: w UTF-8 działają wszędzie, w niewłaściwie odczytanym pliku zamieniają się w krzaki.
Jak sprawdzić kodowanie
W PowerShellu wystarczy odczytać pierwsze bajty pliku. Początek FF FE oznacza UTF-16 LE, EF BB BF to UTF-8
z BOM, brak znacznika zwykle oznacza UTF-8 bez BOM. Można też otworzyć plik w dowolnym edytorze, który pokazuje
kodowanie w pasku stanu. Cały przegląd repo da się zrobić jednym skryptem, który sprawdza nagłówki wszystkich
plików kodu.
Konwersja
Najbezpieczniej odczytać plik jako UTF-16 i zapisać jako UTF-8 (bez zmiany treści). Po konwersji od razu kompiluję bota z linii poleceń (zob. kompilacja z CLI), żeby potwierdzić, że MetaEditor wciąż czyta plik poprawnie. Zwracam uwagę na dwie rzeczy: konwersja to osobny commit (żeby diff z prawdziwą zmianą nie był zmieszany z przepisaniem całego pliku) i musi być przeprowadzona zanim zacznę edytować treść.
Blokada hookiem
Samo pilnowanie na oko zawodzi, więc w repo działa hook przed commitem: wykrywa plik w UTF-16 i przerywa commit. Konwersję robię wtedy świadomie, a nie dopiero wtedy, gdy ktoś zauważy nieczytelny diff w pull requeście. Zasada ogólna: ostrzeżenie, które można zignorować, jest ignorowane, więc blokuję to, co naprawdę psuje pracę.
Checklista
- Nowy plik zapisany w UTF-8 od początku.
- Pobrany kod sprawdzony pod kątem kodowania, zanim trafi do repo.
- Konwersja kodowania w osobnym commicie, bez zmian treści.
- Po konwersji bot kompiluje się bez błędów.
- Hook przed commitem blokuje UTF-16.
- Polskie znaki w komentarzach wyświetlają się poprawnie w gicie.
Powiązane
Źródła
Brak źródeł zewnętrznych - opis praktyki pracy z repozytorium botów.
Ostrzeżenie: artykuł ma charakter edukacyjny i nie jest poradą inwestycyjną. Konwersję kodowania wykonuj na kopii lub w repozytorium z historią. Handel na rynkach finansowych wiąże się z ryzykiem utraty kapitału.