100% в браузъра · файлът никога не напуска компютъра ви · безплатно, без регистрация

Речник на грешките · пълно ръководство

Файлът не е UTF-8 — грешно кодиране на SAF-T файла

Кирилицата на екрана ви изглежда идеално, а системата отказва файла. В 9 от 10 случая причината е Windows-1251 вместо изискваното UTF-8 кодиране.

КатегорияГрешка „на входа“ / при разбор на XML

Кога се хващаОще при отваряне на файла от парсера — преди схемната проверка

Типичен сигналInvalid byte … of … UTF-8 sequence или отказ на входа

Какво значи

Кодирането определя как буквите се записват като байтове. SAF-T файлът трябва да е в UTF-8 — международния стандарт, при който всяка кирилска буква заема два байта. Старите Windows програми обаче често записват текст в Windows-1251 (кирилица в един байт на буква). Двете кодирания са несъвместими на байтово ниво.

Коварното е, че на вашия екран всичко изглежда нормално: текстовите редактори под български Windows отварят Windows-1251 без да се оплачат. Но XML парсерът на приемащата система чете байтовете буквално — и когато декларацията твърди encoding="utf-8", а байтовете са Windows-1251, разборът се проваля на първата кирилска буква. Обратната комбинация (декларация windows-1251 с каквито и да е байтове) също не минава, защото самото изискване е файлът да е UTF-8.

Защо се случва

  • Старият софтуер експортира в Windows-1251 по подразбиране. Класика при системи, писани преди години за българския пазар. Кирилицата в имената на контрагенти и описанията излиза в еднобайтово кодиране.
  • Файлът е редактиран на ръка и презаписан. Отворили сте XML-а в стар редактор (или Notepad с настройка ANSI), поправили сте нещо дребно и сте записали — редакторът тихо е сменил кодирането на целия файл.
  • Декларацията лъже. Първият ред казва encoding="utf-8", но програмата реално е записала Windows-1251 байтове. Декларацията е само етикет — тя не конвертира нищо.
  • Слепени са части с различно кодиране. Ако файлът се сглобява от няколко източника (счетоводна + складова система), една част може да е UTF-8, а друга — не. Такъв файл се чупи „по средата“, на пръв поглед на случаен ред.

Как се поправя

  1. Първо опитайте в източника: потърсете настройка „Encoding / Кодова таблица / UTF-8“ в експорта на счетоводния софтуер. Това е трайното решение — конвертирането на ръка ще ви чака всеки месец.
  2. Ако няма настройка: отворете файла в Notepad++ → меню Encoding. Ще видите текущото кодиране. Изберете Convert to UTF-8 (не „Encode in UTF-8“ — „Encode“ само сменя етикета, „Convert“ преобразува байтовете) и запишете.
  3. Проверете първия ред на файла — декларацията трябва да е <?xml version="1.0" encoding="utf-8"?>.
  4. Отворете файла повторно и прегледайте кирилицата: ако видите първа или ????? вместо български текст, конверсията е минала в грешна посока — върнете се към оригиналния експорт и повторете.

Пример

Един и същи запис, видян „през очите“ на UTF-8 парсер:

Грешно (байтове Windows-1251)
<?xml version="1.0" encoding="utf-8"?>
<!-- декларацията казва utf-8,
     но байтовете са Windows-1251 -->
<Name>Àëôà Òðåéä ÎÎÄ</Name>
<!-- парсерът спира с:
     Invalid byte 1 of 1-byte
     UTF-8 sequence -->
Вярно (байтове UTF-8)
<?xml version="1.0" encoding="utf-8"?>
<Name>Алфа Трейд ООД</Name>
<!-- всяка кирилска буква е
     два байта; парсерът чете
     файла без грешка -->
UTF-8 с BOM (три служебни байта в началото, които някои редактори добавят) е технически валиден UTF-8, но ако приемащата система е капризна, по-безопасният вариант в Notepad++ е Convert to UTF-8 (без BOM).
Не гадайте — проверете

Пуснете файла през безплатната проверка: всяка грешка идва с ред, обяснение и съвет. Проверете файла — безплатно, в браузъра.

Провери файла