Refactor name validation: remove numeric check and simplify character validation#1630
Merged
Zykem merged 8 commits intoesx-framework:devfrom May 9, 2025
Merged
Refactor name validation: remove numeric check and simplify character validation#1630Zykem merged 8 commits intoesx-framework:devfrom
Zykem merged 8 commits intoesx-framework:devfrom
Conversation
… validation - Removed the redundant numeric check as it is already handled by the character validation. - Simplified the name validation logic by keeping only the `checkValidCharacter()` function for validating characters. - The `checkValidCharacter()` function checks for allowed characters: Latin, Greek, Cyrillic, Hebrew, Arabic, and CJK. - Updated `checkNameFormat()` to rely solely on the new character validation logic.
Zykem
requested changes
May 5, 2025
Contributor
Zykem
left a comment
There was a problem hiding this comment.
Move the function checkValidCharacter to an ESX core function named ESX.IsValidLocaleString.
Do not check all character ranges globally. Instead, determine the character range based on the user's selected locale from the config.
For example, if the locale is set to zh-cn, validate only Chinese characters. Do not check for Russian, Arabic, or other unrelated character sets.
However, the following character ranges must always be allowed regardless of the selected locale:
- Basic Latin uppercase (A–Z)
- Basic Latin lowercase (a–z)
- Space and dash (
,-) - Latin Extended
…racter sets Replaced the manual character validation logic in checkNameFormat with ESX.IsValidLocaleString to centralize string validation and allow configuration of valid character sets per locale. Added support for Config.ValidCharacterSets to enable or disable specific Unicode blocks such as Greek, Cyrillic, Hebrew, Arabic, or CJK (Chinese, Japanese, Korean). This change introduces greater flexibility for multilingual servers while maintaining basic Latin character support by default.⚠️ Behavior changes: Characters that were previously allowed may now be rejected depending on the server’s locale configuration.
…ed characters 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.
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.
Zykem
reviewed
May 7, 2025
Zykem
reviewed
May 7, 2025
…eString - 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.
Zykem
reviewed
May 8, 2025
Replaces manual loop for copying `defaultRanges` into `validRanges` with `table.unpack`. Avoids unnecessary iteration and duplication.
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.
Contributor
|
Documentation update regarding your Pull Request. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR refactors the name validation logic by removing the redundant numeric check and simplifying the character validation to handle various character sets like Latin, Greek, Cyrillic, Hebrew, Arabic, and CJK. This change improves the validation process and ensures that only valid characters are accepted, making it more flexible for different language users within the community.
Motivation
The previous validation logic had a redundant numeric check, which was unnecessary because it was already covered by the new character validation logic. This update simplifies the code, improving code readability and making the validation process more flexible. It better supports a wider range of languages and scripts, which is an important step toward making the framework more inclusive for a global community.
Implementation Details
The 'checkValidCharacter()' function is now responsible for validating characters based on their Unicode code ranges, including Latin, Greek, Cyrillic, Hebrew, Arabic, and CJK characters.
The numeric check has been removed as it was redundant.
The 'checkNameFormat()' function now solely depends on 'checkValidCharacter()' to validate names.
This change is also a step toward ensuring that the ESX framework continues to grow in a way that is inclusive and beneficial for developers around the world.
Usage Example
The following function validates a name:
PR Checklist