Skip to content

Refactor name validation: remove numeric check and simplify character validation#1630

Merged
Zykem merged 8 commits intoesx-framework:devfrom
YOMAN1792:dev
May 9, 2025
Merged

Refactor name validation: remove numeric check and simplify character validation#1630
Zykem merged 8 commits intoesx-framework:devfrom
YOMAN1792:dev

Conversation

@YOMAN1792
Copy link
Copy Markdown
Contributor

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:

local function checkNameFormat(name)
    if checkValidCharacter(name) then
        local stringLength = string.len(name)
        return stringLength > 0 and stringLength < Config.MaxNameLength
    end

    return false
end

PR Checklist

  • My commit messages and PR title follow the Conventional Commits standard.
  • My changes have been tested locally and function as expected.
  • My PR does not introduce any breaking changes.
  • I have provided a clear explanation of what my PR does, including the reasoning behind the changes and any relevant context.

… 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.
@github-project-automation github-project-automation bot moved this to 🆕 To be Discussed in ESX Roadmap Apr 23, 2025
Copy link
Copy Markdown
Contributor

@Zykem Zykem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do early returns.

@github-project-automation github-project-automation bot moved this from 🆕 To be Discussed to In-Development in ESX Roadmap Apr 23, 2025
Copy link
Copy Markdown
Contributor

@Zykem Zykem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

YOMAN1792 added 3 commits May 7, 2025 12:23
…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.
Copy link
Copy Markdown
Contributor

@Zykem Zykem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check single comments.

…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.
Replaces manual loop for copying `defaultRanges` into `validRanges` with `table.unpack`.
Avoids unnecessary iteration and duplication.
Zykem
Zykem previously approved these changes May 8, 2025
Copy link
Copy Markdown
Contributor

@Zykem Zykem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@github-project-automation github-project-automation bot moved this from In-Development to Ready for Next Update in ESX Roadmap May 8, 2025
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.
Copy link
Copy Markdown
Contributor

@Zykem Zykem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thanks!

@Zykem
Copy link
Copy Markdown
Contributor

Zykem commented May 9, 2025

Documentation update regarding your Pull Request.
esx-framework/esx-legacy-documentation@f0dd53e

@Zykem Zykem merged commit 605fad5 into esx-framework:dev May 9, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Ready for Next Update

Development

Successfully merging this pull request may close these issues.

3 participants