Ошибки при использовании русских символов.

Доброго времени суток, сломал уже всю голову с решением данной проблемы. Хотелось бы услышать ваши мысли и рассуждения.

Имеем 3 файла: new.pwn в папке gamemodes, loc.inc и test.inc в папке pawno/include. Содержание этих файлов:

new.pwn

PHP код:

---

#include <a_samp>

#include <loc>
#include <test>

main() 
{
    TestFunc();
} 


---

loc.inc

PHP код:

---

#define L_TEST "тест" 


---

test.inc

PHP код:

---

TestFunc()
{
    print(L_TEST);
} 


---

При компиляции данного набора компилятор просто крашится без объяснения причин, однако если заменить в файле loc.inc "тест" на "test", то всё прекрасно работает. Если перенести #define L_TEST в new.pwn или test.inc, то всё также замечательно компилируется.

Файлы пробовал сохранять как стандартным pawno, так и другими текстовыми редакторами в кодировке Windows 1251.

А версия компилятора?

Цитата:

---

Сообщение от tnc

А версия компилятора?

---

Пробовал как стандартным(идёт в комплекте с сервером), так и последним релизом(3.10.9) компилятора от Zeex.

А если, к примеру, вынести сток с main, допустим, в OnGameModeInit?

Цитата:

---

Сообщение от Pa4enka

А если, к примеру, вынести сток с main, допустим, в OnGameModeInit?

---

Если ты про перенос функции TestFunc() в OnGameModeInit, то нет, это не помогает. Всё также крашится.

Заархивируй все файлы вместе с компилятором и скинь сюда. Так будет проще, чем сидеть и гадать.

Цитата:

---

Сообщение от DeimoS

Заархивируй все файлы вместе с компилятором и скинь сюда. Так будет проще, чем сидеть и гадать.

---

https://yadi.sk/d/HyropWONz5ZMzQ

Не нужно ничего кидать. Баг давно зарепортили и выяснили, что компилятор падает из-за разных кодировок в исходных файлах, т.е. он пытается интерпретировать текст инклуда в кодировке UTF-8, когда на самом деле кодировка другая (например, Windows-1251).
https://github.com/pawn-lang/compiler/issues/181
Проблему эту до сих пор не исправили, но в качестве обходного решения (и просто с точки зрения здравого смысла) можно пересохранить файлы в одной кодировке (UTF-8, к примеру). И не забудьте заранее сделать резервную копию всех файлов, на случай, если символы кириллицы превратятся в "крокозябры" после перекодировки.

Цитата:

---

Сообщение от Daniel_Cortez

Не нужно ничего кидать. Баг давно зарепортили и выяснили, что компилятор падает из-за разных кодировок в исходных файлах, т.е. он пытается интерпретировать текст инклуда в кодировке UTF-8, когда на самом деле кодировка другая (например, Windows-1251).
https://github.com/pawn-lang/compiler/issues/181
Проблему эту до сих пор не исправили, но в качестве обходного решения (и просто с точки зрения здравого смысла) можно пересохранить файлы в одной кодировке (UTF-8, к примеру). И не забудьте заранее сделать резервную копию всех файлов, на случай, если символы кириллицы превратятся в "крокозябры" после перекодировки.

---

Благодарю.

 Бесполезный коммент

Цитата:

---

Сообщение от Daniel_Cortez

Не нужно ничего кидать. Баг давно зарепортили и выяснили, что компилятор падает из-за разных кодировок в исходных файлах, т.е. он пытается интерпретировать текст инклуда в кодировке UTF-8, когда на самом деле кодировка другая (например, Windows-1251).
https://github.com/pawn-lang/compiler/issues/181
Проблему эту до сих пор не исправили, но в качестве обходного решения (и просто с точки зрения здравого смысла) можно пересохранить файлы в одной кодировке (UTF-8, к примеру). И не забудьте заранее сделать резервную копию всех файлов, на случай, если символы кириллицы превратятся в "крокозябры" после перекодировки.

---

К слову, вот вырезка из диалога AGraber и Nexius_Tailer с предположительной причиной падения компилятора:

 Nexius_Tailer

I recently remembered this issue and now really wondered why this problem doesn't occur on the "no-utf8" version and why the main version still has this problem if a solution has been found?

 AGraber

I think the reason why it crashes is that the compiler attempts to interpret text outside the ASCII standard table (> 127) as UTF-8, but fails to do so properly and crashes. Building the compiler with the "NO_UTF8" definition skips everything UTF-8 related, so it reads the text "as-is", without trying to do anything funny.

Перевод:

 Nexius_Tailer

Я недавно вспомнил об этой проблеме и теперь действительно задался вопросом, почему эта проблема не возникает на версии "no-utf8" и почему основная версия все еще имеет эту проблему, если решение было найдено?

 AGraber

Я думаю, что причина краша заключается в том, что компилятор пытается интерпретировать текст вне стандартной таблицы ASCII (> 127) как UTF-8, но не делает этого должным образом и крашит. Построение компилятора с определением "NO_UTF8" пропускает все, что связано с UTF-8, поэтому он читает текст "как есть", не пытаясь сделать ничего смешного.

Тоесть при "NO_UTF8" компилятор читает код "как есть", и поэтому компилятор не крашит. А без "NO_UTF8" компилятор интерпретирует utf-8 в ascII, в этом и причина краша.

P.S. "не пытаясь сделать ничего смешного" - под "смешным" скорее всего имелись ввиду "кракозябры" при неправильной кодировке латиницы.