Add Regular Expressions to an Application Webform

Hi Questetra users! I’m Hatanaka, Questetra’s CTO.

We have been improving the web application form App, but the application form only conducts a mandatory check to make sure your e-mail address/phone number has been entered.

Phone Number Verification through Web Form Application

Although under the current mechanism an application can not be submitted if the entered email address or phone number is wrong, obviously incorrect entries should be rejected immediately upon entry of the data.

Thus, I will revise the settings on the Email address and Phone number Data Items. I’m going to add a check that uses a “Regular expression”. Here is a table of what I have changed. I have omitted other items since they have not been changed.

M206: Mandatory Check and Input Format Check on Each Data Item

Since the regular expression is simpler for phone numbers, I will explain this first. It is assumed that only telephone numbers in Japan will be supported.

According to the Ministry of Internal Affairs and Communications (MIC) of Japan, phone numbers in Japan are classified into 6 categories as follows.

• [Numbers starting with 00] Used when making phone calls using a relaying telephone company or making international calls.
• [Numbers starting with 0A0 (A is a number other than 0)] Used to call a mobile phone, PHS, pager, IP phone, etc.
• [Numbers starting with 0AB0 (A and B are numbers other than 0)] Use this when using advanced telephone services provided by the telephone company.
• [Numbers starting with 0ABC (A, B, C are numbers other than 0)] Used to call a landline. (Long distance calls)
• [Numbers starting with 1] Used for important and supplementary services in the aspects of urgency, commonality, and safety.
• [Numbers starting with 2 to 9] Used when calling a landline phone. (Local call)

Of these, the following two are what I suppose I should deal with.

• [Numbers starting with 0A0]
• [Numbers starting with 0ABC]

Moreover, numbers starting with 0A0 are defined as:

• 11-digit numbers starting with 070, 080 or 090 are for mobile phones and PHS.
• 11-digit numbers starting with 0204 are for pagers.

Even though there is no mention of IP phones on the MIA website, they have 11-digits starting with 050.

Numbers starting with 0ABC are numbers of 10 digits in total which consist of:

• 0
• 5 digits of area code/local station number
• 4 digits of subscriber number

(Excluding the leading 0, 9 digits in total)

In addition to this, the telephone number must start with the country code since Twilio is a global service. Thus the regular expression will specify to start with +81, and then the remaining 9 or 10 digits, as shown below. 81 is the country code of Japan. According to the MIC, 81 must not be followed a 0. However, the regular expression will not specify this.

\+81\d{9,10}

Next, I will explain the email address. The specification of an email address (according to the RFC) is extremely complicated and it is difficult to cover all patterns. In the past, there were cell phone carriers that allowed the issuance of RFC violating email addresses that are not in compliance with the specifications. They said nominally that it was a measure against spam emails.

Well, the manual on this site introduces the following.

R2060 Regular Expression

[a-zA-Z0-9][a-zA-Z0-9_\.\-+]*@[A-Za-z0-9\.\-]+

Here in this article, I will specify the following regular expression.

[-!#-'*+/-9=?A-Z^-~]+(?:\.[-!#-'*+/-9=?A-Z^-~]+)*@[-!#-'*+/-9=?A-Z^-~]+(?:\.[-!#-'*+/-9=?A-Z^-~]+)*

This is a regular expression that is actually being used inside Questetra BPM Suite, which excludes the following from RFC 5322 Address Specification.

• Comments
• Spaces
• Control characters
• IP addresses
• Obsolete formats in RFC 2822
• Formats containing a quote-string

It is different from the one introduced on the Support site for the following reasons;

• It excludes periods at the end, consecutive periods (dots) and periods immediately before and after the @ symbol.
• The range of available symbols is wider.

I consider this to be sufficient at present, and have adopted it.

By configuring the regular expression like this, inputs that are obviously not an email address or phone number can be avoided.

Furthermore, I would like to add a Placeholder and Description.
Although the input check has been set, applicants do not yet know what kind of input check will be done.
Therefore, it is desirable to explain this appropriately using a Placeholder and a Description.

Please enter only single-byte alphanumeric symbols

Please start with the country code (+81).
Only numeric symbols without a hyphen.

There are pros and cons when utilizing a placeholder.

The most negative opinion is that since the placeholder disappears, you should not mention important matters such as cautions. Even if you do use it, it will be more appropriate to use it for examples.

There is another negative opinion that it can’t be distinguished from the initial value. If it is easily recognizable as an example, the possibility of being mistaken for an initial value will be low. Even so, it can be difficult to decide what the example should be.

In this way, considering the potential difficulties of using Placeholders, one option is to not use them at all.

Using the above settings for Placeholder/Description, the application form will appear like the following figure.

In this article, I worked on adding an input check for the phone number and the email address. I also set descriptions and placeholders so that the contents of the input check will be understood by the applicant. That’s it for today. See you around.