0

I am writting a Webapplication with PHP Symfony Admin bundle and the input field accepts non latin characters on the Laptop but not on an iPad. The error message on iPad only says that you have to fill out this field.

Schorg
  • 1
  • 2
  • welcome to SO. please be a bit more specific on how you validate your HTML user input exactly and how you test it. – LBA Jul 19 '22 at 14:07
  • From the title I think it's safe to assume they're using `` (but you're not wrong). – RickN Jul 19 '22 at 14:12
  • Does this answer your question? [UTF-8 all the way through](https://stackoverflow.com/questions/279170/utf-8-all-the-way-through) – gp_sflover Jul 19 '22 at 18:35

1 Answers1

0

It depends on what browser you're using on desktop, but yes, that's possible. It's a little bit complex.

First, about allowed characters in domain names:

Domain names used to only allow a-z0-9- characters. For the sake of brevity, let's call these "ASCII-only domains". Later there was a need for more character sets, making example.セール or セール.jp possible (IDN). However, what to do with old systems that can't handle those characters?

The solution was to use Punycode encoding. For example, while .ws uses "odd" characters, the encoded xn--2o8h.ws only uses ASCII characters. Try copying https://.ws to your address bar. Some browsers will show the emoji in the address bar, others will show the punycode equivalent.

As for (domain names in) e-mail addresses:

The HTML specification for <input type="email"> says to validate e-mail addresses in a way that only supports ASCII characters in the domain name.

Most browsers, including current Safari on iOS as you've noticed, don't allow non-ASCII characters. Firefox is one exception: Before it validates, it converts the input to Punycode and then validates that.

If you open this example page in Firefox you'll see two green (valid) input boxes. In most other browsers the top one will be red (invalid).

As for the part before the domain name:

The local part of an e-mail address (the "user" in "user@domain.tld") is for all intents and purposes ASCII-only. Some software packages support UTF-8 encoded characters, many do not.

This answer notes that support for internationalized local parts is specified in (the proposed) RFC 6531 and I think GMail is one example of a client that has implemented the spec.

Before ditching <input type="email"> for <input type="text"> and custom validation, be sure to check if your e-mail sending software supports non-ASCII e-mail addresses.

RickN
  • 12,537
  • 4
  • 24
  • 28
  • 1
    Probably worth adding a reminder that you should *always* supplement client-side validation with server-side, because it's entirely possible for a browser not to perform the client-side validation *at all*, either because it's not implemented in that browser, or because the user edits the page to see what happens. – IMSoP Jul 19 '22 at 14:53
  • 1
    Very true. Client-side validation is convenience, server-side is security/compliance. – RickN Jul 21 '22 at 09:24
  • Nice alliteration there, I'll try to remember that - "client for convenience, server for security" :) – IMSoP Jul 21 '22 at 09:27