Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for decoding of non-quoted object identifier strings in a non-strict decode mode #35

Open
GoogleCodeExporter opened this issue Jan 28, 2016 · 8 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. private var string: String = '[[{metadata:{fields:
[{width:50,attrname:"NME_NIVEL_FORM",fieldtype:"string"},
{width:4,attrname:"ANO_FORM",fieldtype:"string"}]},rowdata:
[["Doutorado","2006"]],version:2.0}]]';

2. var obj: Object = JSON.decode(string);

3. Error: Unexpected m encountered: because metadata shoud be "metadata"

What is the expected output? What do you see instead?
I would like of one array:
private var array: Array =    [[{metadata:{fields:
[{width:50,attrname:"NME_NIVEL_FORM",fieldtype:"string"},
{width:4,attrname:"ANO_FORM",fieldtype:"string"}]},rowdata:
[["Doutorado","2006"]],version:2.0}]];

What version of the product are you using? On what operating system?
0.9



Original issue reported on code.google.com by marcin...@gmail.com on 4 Sep 2007 at 12:50

@GoogleCodeExporter
Copy link
Author

Original comment by mikechambers on 2 Jul 2008 at 4:40

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

This is a strict mode / non-strict mode change.  When strict mode is turned off 
we
should allow for decoding of non-quoted object identifier strings.

It is not valid JSON to have object identifiers not have quotes.  However, a 
lot of
other JSON lirabries seem to output these invalid strings by default.

So, when strict mode is ON, a parse error should be generated as is the current 
behavior.

When strict mode is OFF, we should process the identifier like it was a string 
even
if it isn't enclosed in quotes

Original comment by darron.schall on 23 Oct 2008 at 2:15

  • Changed title: Allow for decoding of non-quoted object identifier strings in a non-strict decode mode
  • Added labels: Type-Enhancement, strict
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

Original comment by mikechambers on 7 Nov 2008 at 7:28

@GoogleCodeExporter
Copy link
Author

Issue 83 has been merged into this issue.

Original comment by darron.schall on 10 Dec 2008 at 4:46

@GoogleCodeExporter
Copy link
Author

I'm interested in which JSON libraries you know of that emit unquoted property 
names. The es5-discuss mailing list is currently discussing whether the 
standard ES5 
JSON parser will need to accept them.

Original comment by davidsar...@googlemail.com on 4 Jun 2009 at 10:16

@GoogleCodeExporter
Copy link
Author

Has this issue been resolved yet?  Been expecting it to be resolved since last 
Winter
break...tried the latest version but to no avail

Original comment by evan_m...@sympatico.ca on 12 Jul 2009 at 1:07

@GoogleCodeExporter
Copy link
Author

@evan - No, this has not been resolved yet.  However, as long as you're using 
properly formatted JSON you 
shouldn't run into trouble.

I'm still debating if this is really worth implementing because it goes against 
JSON syntax (per es5 discussions).  
If a library claims to output JSON strings, then the library should be using 
quoted object keys.

Original comment by darron.schall on 13 Jul 2009 at 2:55

@GoogleCodeExporter
Copy link
Author

@darron - Oh ok, thank you very much for your prompt reply.  See we are working 
with
Moodle and the MySql database doesn't allow for quoted values to be stored.  
From
what I understand, that is one of the reasons why there is a demand and use 
case for
parsing non-quoted JSON strings.

Any chance we may re-consider?  What options do you there are?


Original comment by evan_m...@sympatico.ca on 13 Jul 2009 at 2:21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant