Skip to content

Could Parse Platform support unicode field name #5156

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

Closed
nuxwork opened this issue Oct 30, 2018 · 3 comments
Closed

Could Parse Platform support unicode field name #5156

nuxwork opened this issue Oct 30, 2018 · 3 comments

Comments

@nuxwork
Copy link

nuxwork commented Oct 30, 2018

I found the Parse Platform not supported unicode field name, but javascript and mongodb supported, I review the code and found regex of the key is only supported english alphabet.

    for (var key in attrs) {
      if (!/^[A-Za-z][0-9A-Za-z_]*$/.test(key)) {
        return new _ParseError.default(_ParseError.default.INVALID_KEY_NAME);
      }
    }

The fact that most modern programming languages support Unicode naming illustrates the real existence of this requirement and the forward-looking nature of programming language developers.

The following is a programming language that supports Chinese naming in English. The link is a sample code for the demo:

C, C++, C#, CoffeeScript, Common Lisp, FASM, Go, Haskell, Java, JavaScript, Kotlin, MySQL,Objective-C, Perl, PHP, Python 3, R, Ruby, Scala, Sqlite3, Swfit,

The above is only a test language version that has been verified by the test. Earlier versions and other languages are probably already supported. Unicode strings - Rosetta Code lists more programming languages' support for Unicode, which can be tested one by one.

@flovilmart
Copy link
Contributor

Keys are intended to be consumed in other languagesc that may not support this feature. Because the server exposes it all through a REST API, it is impossible to know ahead of time if the client supports this encoding ahead of time.

@nuxwork
Copy link
Author

nuxwork commented Nov 3, 2018

Keys are intended to be consumed in other languagesc that may not support this feature. Because the server exposes it all through a REST API, it is impossible to know ahead of time if the client supports this encoding ahead of time.

How about unified use UTF-8 encoding?

@flovilmart
Copy link
Contributor

I don’t see the benefit of it directly as it should always be possible for the developer to use keys that match the current valuation pattern.
If you wish to implement a Pr that adds the support for another validation strategy, feel free to do so, but by default I wish to maintain the current behavior.

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

No branches or pull requests

2 participants