ESX.IsValidLocaleString only checks that the argument is a string, but a Lua
string is a byte array and need not be valid utf8. utf8.codes raises on a
malformed sequence rather than stopping, so the function throws where its
annotation promises a boolean.
esx_identity feeds raw client input into it through checkNameFormat, so a
modified client sending a lone 0xFF byte as a first name aborts the
registerIdentity callback before cb() runs. The client is left waiting on a
promise that never resolves and cannot get past the identity screen, and it
can be repeated at will.
utf8.len returns nil instead of raising, so it is enough to reject the string
up front.
Verified on artifact 25770: "Jo\255hn" used to raise "invalid UTF-8 code" and
now returns false. "John" still returns true, "Jo!hn" still returns false, and
"Jo3hn" with allowDigits still returns true.
When a key is absent from the active locale, Translate now borrows the English string instead of returning a placeholder. Locale loading is factored out so the target and English tables are lazily cached. Toggle with the esx:localeFallback convar (on by default) or per-resource Config.LocaleFallback.
Modified the ESX.IsValidLocaleString function to accept an optional `allowDigits` parameter.
When true, the function now allows numerical characters (0-9) in addition to the configured character ranges.
This improves string validation flexibility across locales.
- Replaced `ipairs` with a numeric `for` loop in the UTF-8 validation step for better performance.
- Stored `validRanges[i]` in a local `range` variable to avoid duplicate table lookups.
- Added a call to `ESX.ValidateType(str, 'string')` to ensure input is of type string before processing.
These changes improve both performance and code safety.
This update introduces a new configuration option `Config.ValidCharacterSets` to allow support for additional character sets in case the server is multilingual. This allows the server to handle character sets such as Greek, Cyrillic, Hebrew, Arabic, and East Asian languages (Chinese, Japanese, Korean).
By default, these character sets are disabled (`false`). The user can enable them if needed, depending on the language requirements of the server.
This commit introduces the new `ESX.IsValidLocaleString` function, which checks if a given string contains valid characters based on the configured locale. It validates characters from various locales, such as Greek, Cyrillic, Hebrew, Arabic, and Chinese, in addition to basic Latin characters. The function is flexible, allowing for the inclusion of additional character sets via the `Config.ValidCharacterSets` configuration.
Changes include:
- A new function, `ESX.IsValidLocaleString`, added to validate characters based on the locale.
- The validation takes into account default Latin ranges as well as specific ranges for supported languages.
- The function supports dynamic locale configurations by using `Config.ValidCharacterSets`.
This refactor improves handling of locale-specific characters and provides a way to easily extend validation for new locales as needed.
_Not_