FieldValuesAsText re-encodes underscores in JSON keys

Symptom

You fetch formatted values for an item:

GET /_api/web/getfilebyserverrelativeurl('/sites/x/Docs/report.docx')/ListItemAllFields/FieldValuesAsText

and look up your column by its internal name (Document_x0020_Type). The key is missing from the JSON — even though the column clearly has a value in the UI. Columns with simple names (Category) work fine.

Cause

Internal names created from display names with spaces already contain OData-encoded sequences (_x0020_ for a space). When FieldValuesAsText serialises the response, it encodes the underscores of that encoding once more: each _ becomes _x005f_. Your Document_x0020_Type arrives as Document_x005f_x0020_x005f_Type.

Fix

Normalise the response keys before matching:

const dict: { [k: string]: string } = {};
Object.keys(resp).forEach(k => {
  const v = resp[k];
  if (typeof v !== 'string') return;
  dict[k.toLowerCase()] = v;                                   // raw key
  dict[k.split('_x005f_').join('_').toLowerCase()] = v;        // decoded key
});
const value = dict[internalName.toLowerCase()] || '';

Keeping both the raw and the decoded key makes the lookup safe regardless of whether a given tenant/endpoint applies the re-encoding.

Notes

• FieldValuesAsText is otherwise a great fit for read-only detail views: it returns display-ready strings for every field type, including person, lookup and managed metadata — types you cannot easily render from raw item values.
• The sibling endpoints FieldValuesAsHtml and FieldValuesForEdit show the same key encoding.
• Raw item reads (/items?$select=Document_x0020_Type) are not affected — the re-encoding is specific to the FieldValues* family.