Is there any documentation on the limitations on zookeeper node names? I can't find anything in official documentation regarding it. In particular, I want to know:
What characters are allowed?
Can I use any character from UTF-8 (like japanese characters)?
What is the maximum limit of characters/bytes (if any) for node name?
For 1, 2: Any unicode character can be used in a path subject to the following constraints:
The null character (\u0000) cannot be part of a path name. (This causes problems with the C binding.)
The following characters can't be used because they don't display well, or render in confusing ways: \u0001 - \u001F and \u007F - \u009F.
The following characters are not allowed: \ud800 - uF8FF, \uFFF0 - uFFFF.
The . character can be used as part of another name, but . and .. cannot alone be used to indicate a node along a path, because ZooKeeper doesn't use relative paths. The following would be invalid: /a/b/./c or /a/b/../c.
The token zookeeper is reserved.
PS: The source code: PathUtils.validatePath()
For 3: In fact, there is no limit on the length of name in ZK itself, but is is recommended not using too large name (e.g., ZK store entire data in memory for efficiency)
We just added Swiftlint to our project and we want to follow all the rules but I'm not sure what's meant by 'type_body_length' warning. I'm not a native english speaker so I find it a bit confusing.
There is a rule for file length aswell so how do they differ? What falls under this definition?
type_body_length violation means that the class has too many lines in it. I dont think it counts extensions, comments or whitespace
Type name should only contain alphanumeric characters, start with an uppercase character and span between 3 and 40 characters in length.
The rules documentation linked here and above also gives examples of what would and wouldn't be accepted (Triggering & Non Triggering). - Edit suggested by #GoodSp33d, thanks
As explained at https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
labels name and value have limit of 63 characters. Does anyone know what drives this limit? I am not looking for code condition but the real reason behind choosing this value.
As Suresh Vishnoi wrote, it is a global restriction based on RFC-1123.
Here is a simple explanation of this restriction.
There is a commit in Kubernetes which provides the validation of labels' length.
Here is design documentation of the kubernetes. The following link provides detail information.
rfc1035/rfc1123 label (DNS_LABEL): An alphanumeric (a-z, and 0-9) string, with a maximum length of 63 characters, with the '-' character allowed anywhere except the first or last character, suitable for use as a hostname or segment in a domain name.
identifiers-and-names-in-kubernetes
Some people will reply that domain names are not case-sensitive. In the new Unicode world this is no longer true.
(Source)
I thought one of the steps in the Unicode > Punycode conversion was a "normalisation", which rendered domain names lower case.
For old-fashioned ASCII-based domain names, Yes, domain names have been and continue to be case-insensitive.
To quote RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION:
Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.
For example, all of these represent the same domain:
example.com
Example.com
EXAMPLE.COM
EXampLE.com
In modern DNS, we now have Internationalized Domain Names (IDN) which allows Unicode characters. The problem is that defining upper- and lowercase can be tricky in some languages and character sets beyond ASCII (Unicode is a superset of US-ASCII).
The intent of domain names is to be case-insensitive, but there may be complications with particular characters in particular scripts of particular human languages. So there is no simple YES or NO answer to your question.
If using non-ASCII domain names, you should read:
Internationalized domain name on Wikipedia
Domain Name System (DNS) Case Insensitivity Clarification Official spec (IETF RFC 4343)
WRONG: URLs are still case insensitive, even for IDN.
CORRECTION:
The question was about IDN: "Are IDN domain names case-sensitive?"
My initial answer is wrong, and does not clearly answer the question.
It brings URLs into the mix.
The domain name part (IDN) of a URL is case-insensitive.
The other elements might be case-insensitive or not. It depends on many things, and in general is not predictable.
For instance the path part would normally depend on the OS or even the file system hosting the site (on MacOS you can format the drive as case insensitive or not)
But these days you can have some of these paths "hooked" to answer RESTfull APIs.
So it depends on how the "hook" is done.
Similar for other elements (user, password, parameters, parameter values)
I'm building a website using Django. The website could have a significant number of users from non-English speaking countries.
I just want to know if there are any technical restrictions on what types of characters an email address could contain.
Are email addresses only allowed to contain English letters, numbers, _, # and .?
Are they allowed to contain non-English alphabets like é or ü?
Are they allowed to contain Chinese or Japanese or other Unicode characters?
Email address consists of two parts local before # and domain that goes after.
Rules to these parts are different:
For local part you can use ASCII:
Latin letters A - Z a - z
digits 0 - 9
special characters !#$%&'*+-/=?^_`{|}~
dot ., that it is not first or last, and not in sequence
space and "(),:;<>#[] characters are allowed with restrictions (they are only allowed inside a quoted string, a backslash or double-quote must be preceded by a backslash)
Plus since 2012 you can use international characters above U+007F, encoded as UTF-8.
Domain part is more restricted:
Latin letters A - Z a - z
digits 0 - 9
hyphen -, that is not first or last, multiple hyphens in sequence are allowed.
Regex to validate
^(([^<>()\[\]\.,;:\s#\"]+(\.[^<>()\[\]\.,;:\s#\"]+)*)|(\".+\"))#(([^<>()[\]\.,;:\s#\"]+\.)+[^<>()[\]\.,;:\s#\"]{2,})
Hope this saves you some time.
Well, yes. Read (at least) this article from Wikipedia.
I live in Argentina and here are allowed emails like ñoñó1234#server.com
The allowed syntax in an email address is described in [RFC 3696][1], and is pretty involved.
The exact rule [for local part; the part before the '#'] is that any ASCII character, including control
characters, may appear quoted, or in a quoted string. When quoting
is needed, the backslash character is used to quote the following
character
[...]
Without quotes, local-parts may consist of any combination of
alphabetic characters, digits, or any of the special characters
! # $ % & ' * + - / = ? ^ _ ` . { | } ~
[...]
Any characters, or combination of bits (as octets), are permitted in
DNS names. However, there is a preferred form that is required by
most applications...
...and so on, in some depth.
[1]: https://www.rfc-editor.org/rfc/rfc3696
Instead of worrying about what email addresses can and can't contain, which you really don't care about, test whether your setup can send them email or not—this is what you really care about! This means actually sending a verification email.
Otherwise, you can't catch a much more common case of accidental typos that stay within any character set you devise. (Quick: is random#mydomain.com a valid address for me to use at your site, or not?) It also avoids unnecessarily and gratuitously alienating any users when you tell them their perfectly valid and correct address is wrong. You still may not be able to process some addresses (this is necessary alienation), as the other answers say: email address processing isn't trivial; but that's something they need to find out if they want to provide you with an email address!
All you should check is that the user supplies some text before an #, some text after it, and the address isn't outrageously long (say 1000 characters). If you want to provide a warning ("this looks like trouble! is there a typo? double-check before continuing"), that's fine, but it shouldn't block the add-email-address process.
Of course, if you don't care to ever send email to them, then just take whatever they enter. For example, the address might solely be used for Gravatar, but Gravatar verifies all email addresses anyway.
There is a possibility to have non-ASCII email addresses, as shown by this RFC: https://www.rfc-editor.org/rfc/rfc3490 but I think this has not been set for all countries, and from what I understand only one language code will be allowed for each country, and there is also a way to turn it into ASCII, but that won't be a trivial issue.
I have encountered email addresses with single quotes, and not infrequently either. We reject whitespace (though strictly speaking it is allowed), more than one '#' sign and address strings shorter than five characters in total. I believe this solves more problems than it creates, and so far over ten years and several hundred thousand addresses it's worked to reject many garbage addresses. Also there is a trigger to downcase all email addresses on insert or update.
That being said it is impossible to validate an email without a round trip to the owner, but at least we can reject data that is extremely suspect.
I took a look at the regex in pooh17's answer and noticed it allows the local part to be greater than 64 characters if separated by periods (it just checked the bit before the first period is less than 64 characters). You can make use of positive lookahead to improve this, here's my suggestion if you're really wanting a regex for this
^(((?=.{1,64}#)[^<>()[\].,;:\s#"]+(\.[^<>()[\].,;:\s#"]+)*)|((?=.{1,66}#)".+"))#(?=.{1,255}$)(\[(IPv6:)?[\dA-Fa-f:.]+]|(?!.*?\.\.)(([^\s!"#$%&'()*+,./:;<=>?#[\]^_`{|}~]+\.?)+[^\s!"#$%&'()*+,./:;<=>?#[\]^_`{|}~]{2,}))$
Building on #Matas Vaitkevicius' answer: I've fixed up the regex some more in Python, to have it match valid email addresses as defined on this page and this page of wikipedia, using that awesome regex101 website: https://regex101.com/r/uP2oL7/26
^(([^<>()\[\]\.,;:\s#\"]{1,64}(\.[^<>()\[\]\.,;:\s#\"]+)*)|(\".+\"))#\[*(?!.*?\.\.)(([^<>()[\]\.,;\s#\"]+\.?)+[^<>()[\]\.,;\s#\"]{2,})\]?
Hope this helps someone!:)