mirror of
https://github.com/Nikolay-Shirokov/cc-1c-skills.git
synced 2026-08-29 14:39:40 +03:00
Nick ShirokovandClaude Opus 5
229e66b907
Этажом ниже разбора, на чтении файла, жил тот же класс дефектов в худшей форме. Файл в 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>
14 lines
399 B
JSON
14 lines
399 B
JSON
{
|
|
"name": "Файл в UTF-16 с BOM читается: кодировка объявлена самим файлом",
|
|
"inputRaw": "{\"type\": \"Catalog\", \"name\": \"Номенклатура\"}",
|
|
"inputEncoding": "utf-16le",
|
|
"params": {
|
|
"validatePath": "Catalogs/Номенклатура.xml"
|
|
},
|
|
"expect": {
|
|
"files": [
|
|
"Catalogs/Номенклатура.xml"
|
|
]
|
|
}
|
|
}
|