Weave Code
Ustring Laravel Package
hoa/ustring
Hoa\Ustring is a PHP library for handling Unicode strings as objects, offering UTF-8-aware manipulation of grapheme clusters, case conversion, search, replace, and iteration for safer, more robust multilingual text processing in PHP applications.
Hoa\Ustring is a PHP library for manipulating UTF-8 strings with Unicode-aware semantics. It wraps strings in a fluent, object-oriented API so operations like length, slicing, searching, and replacement respect multibyte characters and grapheme clusters instead of raw bytes.
- Unicode-aware
length,substring,indexOf, andreplace - Grapheme and character iteration for safe text processing
- Case conversion and comparison helpers
- Fluent, object-oriented API for readable string handling
- Useful for internationalized applications and text validation
Frequently asked questions about Ustring
- Is hoa/ustring still maintained and compatible with modern Laravel versions?
- No. The hoa/ustring repository is archived and read-only, its last tag dates to January 2017, and there is no upstream issue tracker, maintainer, or release channel to escalate to. Its Composer manifest targets the PHP 5.5 and 7.x era, so installation on the PHP 8.0+ runtimes required by Laravel 9 and later is unverified and typically blocked by platform constraints. Treat it as an unmaintained dependency to contain and remove, not a package to adopt.
- Can I install hoa/ustring in a Laravel 10 or Laravel 11 project?
- You can add it to composer.json, but Composer will usually refuse to resolve it on PHP 8.1+ because of the package's platform constraints. Forcing the install with --ignore-platform-req=php means shipping code that has never actually executed on your interpreter. Since Laravel 9 and later require PHP 8.0 or newer, there is no supported combination of this package and a current Laravel release.
- Does hoa/ustring work on PHP 8?
- Not officially. The package was last tagged in 2017 when PHP 5.5 and 7.x were the targets, and Hoa packages historically rely on Hoa\Consistency autoloading and hoa:// stream wrapper conventions that sit awkwardly beside Composer 2 and PSR-4 expectations. Even where it loads, the bundled Unicode property and grapheme-break tables are frozen around 2016 to 2017, so results diverge from mbstring and intl on modern text. Do not treat a successful one-off run as PHP 8 support.
- What is the difference between hoa/ustring and Laravel's Str class?
- hoa/ustring is an object-oriented Ustring class implementing ArrayAccess, Countable, and IteratorAggregate, with grapheme-cluster-aware charAt, substring, split, padding, and case conversion. Illuminate\Support\Str and Str::of() provide a fluent Stringable API that covers the same ergonomics most teams originally adopted Ustring for, ships with the framework, and is actively maintained. For a Laravel project, Str is the correct default, and adding Ustring creates a second redundant string abstraction alongside it.
- Is symfony/string a good replacement for hoa/ustring?
- Yes. symfony/string provides AbstractString, UnicodeString, and Slugger with Unicode-aware operations, native PHP 8 support, and active maintenance by the Symfony core team, and it is already present as a transitive dependency in most Laravel codebases. Pair it with the intl extension's grapheme_* functions when you need exact grapheme segmentation. That combination covers everything Ustring was used for without the abandonment risk.
- Does hoa/ustring handle emoji and grapheme clusters correctly?
- Only according to Unicode data frozen around 2016 to 2017. Emoji ZWJ sequences, flag pairs, skin-tone modifiers, and newer script and case-folding data will behave inconsistently compared with mbstring, intl, and whatever your frontend or database collation does. The failure mode is silent divergence rather than a crash, which is worse for character counts and validation. Run a parity corpus with golden-file tests before trusting any grapheme or length output.
- Which PHP extensions does hoa/ustring require?
- It depends on ext-mbstring and ext-iconv for encoding work, and pulls in hoa/consistency and hoa/exception as Composer dependencies. That chain is part of the problem, because it drags a second autoloading convention into your project alongside PSR-4. If you only need multibyte-aware length and case conversion, native mb_* functions plus Str are simpler and already available in every Laravel install.
- Is hoa/ustring safe to use for input validation or length limits?
- No. Disagreement between byte, code-point, and grapheme length is a classic filter-bypass vector, and a library with stale Unicode tables will disagree with your database collation, your frontend counter, and mbstring. If the usage is pure display formatting the risk is low, but if it gates validation, identifier generation, or truncation, treat it as a security-relevant defect. Replace it with mb_* plus Str or symfony/string before you have to reason about it under incident pressure.
- How do I migrate an existing Laravel app off hoa/ustring?
- Start with an inventory: run composer why hoa/ustring to find the direct or transitive path, then grep for Ustring, Hoa\Ustring, and hoa:// usages across your codebase. Wrap each call site in an adapter that delegates to Str, symfony/string, or intl's grapheme_* functions, and delete the dependency once the adapter has no remaining consumers. Keep that adapter boundary strict and never let Ustring objects end up in queue payloads or serialized state.
- Does hoa/ustring have global state or testing problems?
- Yes. It uses class-level default charset configuration, which is hidden global state that can leak across tests and long-running queue workers. That makes behaviour order-dependent and hard to reproduce, especially in parallel test suites. If you must keep it temporarily, isolate it behind an adapter, set the charset explicitly at every entry point, and never serialize Ustring instances into jobs or cache entries.
Weaver
How can I help you explore Laravel packages today?