Вход

Просмотр полной версии : [Вопрос] Ошибки при использовании русских символов.



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

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

new.pwn

#include <a_samp>

#include <loc>
#include <test>

main()
{
TestFunc();
}

loc.inc

#define L_TEST "тест"

test.inc

TestFunc()
{
print(L_TEST);
}

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

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

tnc
04.02.2020, 02:03
А версия компилятора?

Landyani
04.02.2020, 02:05
А версия компилятора?

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

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

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

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

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

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

https://yadi.sk/d/HyropWONz5ZMzQ

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

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

Благодарю.

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

К слову, вот вырезка из диалога AGraber и 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?

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.

Перевод:

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

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

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

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