Files
cc-1c-skills/tests/skills/cases/meta-compile/encoding-utf16-bom.json
T
Nick ShirokovandClaude Opus 5 229e66b907 fix(skills): чтение входного JSON — кодировка из BOM, эхо только для inline-значения (#80)
Этажом ниже разбора, на чтении файла, жил тот же класс дефектов в худшей форме. Файл в cp1251
с кириллицей: PS1 `Get-Content -Encoding UTF8` менял имя на 12 символов U+FFFD, JSON после этого
разбирался УСПЕШНО, и навык создавал объект с именем из «замен» — молча. Py-порт на том же файле
падал traceback-ом. Файл в UTF-16 давал ту же пару: traceback против ложного «JSON must have
'type' field».

Новая семья read_json_file / Read-JsonInputFile: кодировка берётся из BOM (UTF-8, UTF-16 LE/BE),
без BOM — строгий UTF-8, при провале сообщение называет файл и байт. Кодовую страницу не
подбираем: угаданное имя уехало бы в метаданные так же молча.

Эхо полученного значения печатается теперь только для inline-входа. Для файла оно показывало
первые 60 символов первой строки независимо от того, что ошибка на 120-й, и спорило с позицией
от парсера.

Заодно уравнен пустой вход: PS 5.1 на пустой строке отдаёт $null, а не ошибку, и навык уходил
дальше с $null, тогда как py-порт падал.

Раннеру добавлен ключ inputEncoding (utf-16le / utf-16be / cp1251) — иначе кейс про кодировку
не выразить, writeFileSync пишет только UTF-8.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 16:41:54 +03:00

14 lines
399 B
JSON

{
"name": "Файл в UTF-16 с BOM читается: кодировка объявлена самим файлом",
"inputRaw": "{\"type\": \"Catalog\", \"name\": \"Номенклатура\"}",
"inputEncoding": "utf-16le",
"params": {
"validatePath": "Catalogs/Номенклатура.xml"
},
"expect": {
"files": [
"Catalogs/Номенклатура.xml"
]
}
}