OdysseusYuan/LKY_OfficeTools · error · Exception
无法获取 PerpetualVL2021 对应的下载地址!
Error message
无法获取 PerpetualVL2021 对应的下载地址!
What it means
Thrown when the PerpetualVL2021 block is found (latest_info is non-empty) but the baseUrl field cannot be extracted from within it. The code looks for the marker `baseUrl":"` inside the extracted block. Unlike error 24, this fires at a later stage: the channel block exists but the download-URL field is absent or reformatted. The resulting URL would be combined with a hard-coded "/office/data" suffix to form OfficeUrlRoot.
Source
Thrown at LKY_OfficeTools/Lib/Lib_OfficeInfo.cs:180
{
return null;
}
new Log("\n------> 正在解析 最新可用 Office 下载服务器 ...", ConsoleColor.DarkCyan);
//获取版本信息
string latest_info = Com_TextOS.GetCenterText(OfficeChannelInfo, "\"PerpetualVL2021\",", "name"); //获取 2021 LTSC
if (!string.IsNullOrEmpty(latest_info))
{
//获取office下载地址
var url = Com_TextOS.GetCenterText(latest_info, "baseUrl\":\"", "\""); //官方Json取值,格式和自己的不一样,千万注意
new Log($" √ 已获得 Office 最新下载服务器信息", ConsoleColor.DarkGreen);
return _office_url_root = url + "/office/data";
}
throw new Exception("无法获取 PerpetualVL2021 对应的下载地址!");
}
catch (Exception Ex)
{
new Log(" × 无法获取 最新可用 Office 下载服务器", ConsoleColor.DarkRed);
new Log(Ex.ToString());
return null;
}
}
}
private static List<string> _office_file_list;
internal static List<string> OfficeFileList
{
get
{
try
{
//非空返回View on GitHub (pinned to 6f9a1bd471)
Solutions
- Inspect the raw PerpetualVL2021 block content to see the current field name for the download URL.
- Update the baseUrl marker string in GetCenterText to match Microsoft's current field name/escaping.
- Switch to structured JSON parsing so nested/moved fields are accessed by path, not string markers.
- Verify the resulting URL + "/office/data" still resolves against Microsoft's current CDN layout.
- Add a regression test using a captured channel JSON sample.
Example fix
// before
var url = Com_TextOS.GetCenterText(latest_info, "baseUrl\":\"", "\"");
return _office_url_root = url + "/office/data";
...
throw new Exception("无法获取 PerpetualVL2021 对应的下载地址!");
// after — structured field access with a null-safe message
var json = JObject.Parse(OfficeChannelInfo);
var channel = json["PerpetualVL2021"];
var baseUrlToken = channel?["baseUrl"];
if (baseUrlToken == null)
throw new Exception("PerpetualVL2021 缺少 baseUrl 字段,CDN 结构可能已变更。");
return _office_url_root = baseUrlToken.ToString() + "/office/data"; Defensive patterns
Strategy: fallback
Validate before calling
// Confirm the baseUrl field is present inside the PerpetualVL2021 block before relying on it.
string latest_info = Com_TextOS.GetCenterText(OfficeChannelInfo, "\"PerpetualVL2021\",", "name");
string url = string.IsNullOrEmpty(latest_info) ? null
: Com_TextOS.GetCenterText(latest_info, "baseUrl\":\"", "\"");
if (string.IsNullOrEmpty(url))
{
new Log("PerpetualVL2021 块中缺少 baseUrl 字段,CDN 结构可能已变更。", ConsoleColor.DarkRed);
return;
} Prevention
- Access baseUrl via structured JSON path rather than string markers so nested moves survive.
- Verify the composed URL (<baseUrl>/office/data) resolves against the current CDN after any schema update.
- Unit-test baseUrl extraction against a saved channel JSON sample.
- Log the raw PerpetualVL2021 block on failure so field-name changes are immediately visible.
When it happens
Trigger: (a) The PerpetualVL2021 block is present but the baseUrl field was renamed or removed by Microsoft; (b) the field's escaping/quoting changed so the `baseUrl":"` marker no longer matches; (c) Microsoft restructured the CDN URL field while keeping version data intact (so error 24 passes but this one fires).
Common situations: Microsoft changed the download URL field name in the channel JSON; the JSON escaping changed (e.g., pretty-printed vs compact); a CDN restructure moved baseUrl to a nested object; the channel data was partially published.
Related errors
AI-assisted analysis of OdysseusYuan/LKY_OfficeTools@6f9a1bd471 (2026-08-13).
Data as JSON: /api/errors/778484376fa03753.
Report an issue: GitHub.