Sp-dev-docs: Getting item data from REST API using FieldValuesAsText double-encode internal names

[shaipetel]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

Created field with name: "Français"
Internal name was set to "Fran_x00e7_ais"

Expecting when I get item data from REST API, that the field value would be item.internalName, in this case:
item.Fran_x00e7_ais

Also, when getting the field values as text (using /FieldValuesAsText or $expand=FieldValuesAsText) expected to get the field value in the same way: item.FieldValuesAsText.internalName, in this case:
item.FieldValuesAsText.Fran_x00e7_ais

Observed Behavior

Instead, field value normally comes back corrects: item.Fran_x00e7_ais
but field values as text does not. it seems it is double-encoding the internal name, replacing _ with _x005f_ so the value comes back in:
item.FieldValuesAsText.Fran_x005f_x00e7_x005f_ais

This causes the code to not recognize and pull the field value correctly since we are relying on the field.internalName to pull the value from the REST response.

Steps to Reproduce

Create a column titled: "Français"
Create a sample item
Make a REST API call to get the item data: .../_api/web/lists/getByTitle('FrenchTest')/Items(1)
-- check: you will get the value in the correct internal name: Fran_x00e7_ais
.../_api/web/lists/getByTitle('FrenchTest')/Items(1)/FieldValuesAsText
-- check: you will NOT get the value in the correct internal name. Instead the value will be under Fran_x005f_x00e7_x005f_ais

Suggestion:
since many productions apps now may rely on this double-encoding, you can't fix it without breaking them. I suggest you keep the double encoded name and add the correct internal name value to the FieldValuesAsText result, to keep backward compatibility.

Also note: this happens with FieldValuesAsHTML as well.

[GrahamMcMynn]

@shaipetel - sorry for the slow response here. This happens with common characters such as a space and has been that way since at least the 2016 product. I know you suggested having both values emitted, however, that muddies the values returned and duplicates content. If you would like this changed please make a request on user voice.

[shaipetel]

These types of replies and closing confirmed undisputed bugs in the API really makes it seem useless to bother reporting them.

Opening a user voice can’t be the answer for every ailment. Many developers fall into this pitfall and will continue to - talk about muddy the water - how about muddy the code with special-case field names...

Anyway, this type of issue is exactly the important ones that will never gain traction in user voice reports unless I invest a lot of time promoting it or getting people to vote on it, which I honestly have zero interest in doing. I got my code working, if Microsoft doesn’t seem to care to fix the API, that’s fine with me.

[AhmadiRamin]

@shaipetel I'm facing the exact same issue, can you please tell me how did you fix it?

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues