Language support & regular expressions

Characters such as ñ, é, symbols, and ideographs are sometimes acceptable input. Support varies by the nature of the item being configured. CLI commands, objects, field names, and options must use their exact ASCII characters, but some items with arbitrary names or values may be input using your language of choice.

For example, the host name must not contain special characters, and so the web UI and CLI will not accept most symbols and other non-ASCII encoded characters as input when configuring the host name. This means that languages other than English often are not supported. However, some configuration items, such as names and comments, may be able to use the language of your choice.

The system stores the input using Unicode UTF-8 encoding, but it is not normalized from other encodings into UTF-8 before stored. If your input method encodes some characters differently than in UTF-8, your configured items may not display or operate as expected.

Regular expressions are especially impacted. Matching uses the UTF‑8 character values. If you enter a regular expression using another encoding, or if an HTTP client sends a request in an encoding other than UTF‑8, matches may not be what you expect.

For example, with Shift-JIS, backslashes ( \ ) could be inadvertently interpreted as yen symbols ( ¥ ) and vice versa. A regular expression intended to match HTTP requests containing money values with a yen symbol therefore may not work it if the symbol is entered using the wrong encoding.

• Use only the characters whose numerically encoded values are the same in UTF‑8, such as the US-ASCII characters that are also encoded using the same values in ISO 8859-1, Windows code page 1252, Shift-JIS and other encodings, or


	HTTP clients may send requests in encodings other than UTF-8. Encodings usually vary by the client’s operating system or input language. If you cannot predict the client’s encoding, you may only be able to match any parts of the request that are in English, because regardless of the encoding, the values for English characters tend to be encoded identically. For example, English words may be legible regardless of interpreting a web page as either ISO 8859-1 or as GB2312, whereas simplified Chinese characters might only be legible if the page is interpreted as GB2312.

To configure the system using other encodings, you might need to switch language settings on your management computer, including for your web browser or Telnet or SSH client. For instructions on how to configure your management computer’s operating system language, locale, or input method, see its documentation.


	If you choose to configure parts of the system using non-ASCII characters, verify that all systems interacting with the FortiADC appliance also support the same encodings. You should also use the same encoding throughout the configuration if possible in order to avoid needing to switch the language settings of your web browser or Telnet or SSH client while you work.

Similarly to input, your web browser or CLI client should usually interpret display output as encoded using UTF-8. If it does not, your configured items may not display correctly in the web UI or CLI. Exceptions include items such as regular expressions that you may have configured using other encodings in order to match the encoding of HTTP requests that the system receives.

Support for sending and receiving international characters varies by each Telnet or SSH client. Consult the documentation for your Telnet or SSH client.

Figure 2: Entering encoded characters (PuTTY)

Depending on your Telnet or SSH client’s support for your language’s input methods and for sending international characters, you may need to interpret them into character codes before pressing Enter.