BigPizzaV3/CodexPlusPlus · error · Error

不支持此分享的数据格式。

Error message

不支持此分享的数据格式。

What it means

decryptText() rejects any encrypted payload whose envelope version field v is not exactly 1 before attempting AES-GCM decryption. This is a forward-compatibility guard: the share-site only knows how to decrypt the v=1 envelope {v:1, iv, ciphertext, ...}, and would otherwise produce corrupt or misleading decryption failures on newer formats.

Solutions

  1. Upgrade the share-site (app.js / encryptText writer) so writer and reader agree on the same envelope version.
  2. Log/inspect data.encrypted in the browser console to see the actual v value before assuming corruption.
  3. Pin the encrypting app and share-site to compatible versions during rollout of a format change.
  4. If v is genuinely newer, show a clear 'please update / unsupported share version' notice instead of a generic format error.

Example fix

// before
if (payload?.v !== 1) throw new Error("不支持此分享的数据格式。");
// after
const SUPPORTED_V = 1;
if (payload?.v !== SUPPORTED_V) throw new Error(`不支持此分享的数据格式(版本 ${payload?.v ?? "未知"},需要 v${SUPPORTED_V})。`);
Defensive patterns

Strategy: type-guard

Validate before calling

const payload = data.encrypted;
if (!payload || payload.v !== 1 || !(payload.iv && payload.ciphertext)) {
  viewNotice.textContent = "此分享使用了不受支持的数据格式,请更新客户端。";
  return;
}

Type guard

function isV1Envelope(p) {
  return !!p && p.v === 1 && typeof p.iv === 'string' && typeof p.ciphertext === 'string';
}

Try / catch

try {
  const plaintext = await decryptText(data.encrypted, keyValue);
} catch (e) {
  if (e.message.includes("不支持此分享的数据格式")) {
    viewNotice.textContent = "分享格式版本不受支持,请更新页面或联系分享者。";
  } else { throw e; }
}

Prevention

When it happens

Trigger: Calling decryptText with data.encrypted that is null/undefined, or an object produced by a newer writer using a different envelope version (v !== 1).

Common situations: Server stores shares written by a newer version of the encrypting app than the static share-site JS; the encrypted field was corrupted or replaced; the API returned an error object instead of the expected envelope.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors


AI-assisted analysis of BigPizzaV3/CodexPlusPlus@b1ed92e5e4 (2026-09-19). Data as JSON: /api/errors/65c8e18be8f0c9af. Report an issue: GitHub.

Appendix: source

Thrown at services/share-site/app.js:186

}

async function encryptText(value) {
  const key = await crypto.subtle.generateKey({ name: "AES-GCM", length: 256 }, true, ["encrypt"]);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, encoder.encode(value));
  const exportedKey = await crypto.subtle.exportKey("raw", key);
  return {
    key: toBase64Url(new Uint8Array(exportedKey)),
    payload: {
      v: 1,
      iv: toBase64Url(iv),
      ciphertext: toBase64Url(new Uint8Array(ciphertext)),
    },
  };
}

async function decryptText(payload, keyValue) {
  if (payload?.v !== 1) throw new Error("不支持此分享的数据格式。");
  const key = await crypto.subtle.importKey(
    "raw",
    fromBase64Url(keyValue),
    { name: "AES-GCM" },
    false,
    ["decrypt"],
  );
  const plaintext = await crypto.subtle.decrypt(
    { name: "AES-GCM", iv: fromBase64Url(payload.iv) },
    key,
    fromBase64Url(payload.ciphertext),
  );
  return decoder.decode(plaintext);
}

function toBase64Url(bytes) {
  let binary = "";
  for (const byte of bytes) binary += String.fromCharCode(byte);

View on GitHub (pinned to b1ed92e5e4)