When I use UTF-8 as QApplication::$EncodingType in QTextBoxBase Validate function character counting return a bad value because strlen is not a multibyte safe function.
Changing strlen to mb_strlen and adding QApplication::$EncodingType as second parameter.
Yeah -- the problem is, however, that mb_string (and actually the entire mb_ extension) isn't a “standard” extension for PHP.
I think you're solution does make sense -- I just think we should put it around a “if function_exists()” wrapper so that we don't break BC.
Actually, this probably is a larger task, in general. Obviously the framework uses a lot of string-based methods (strpos, strlen, etc.) which assumes an 8-bit character set. Even though Qcodo is trying to push for UTF-8 by default... the result is that we get slightly quirky behavior when we introduce any multibyte characters.
Originally I was going to defer to the PHP folks, especially with all the push for PHP 6 and native UTF-8 support. However, since PHP 6 has essentially been shelved indefinitely, I think it does make sense to revisit having a clean, standard approach for multibyte/internationalized characters for Qcodo.
I do like continuing to have UTF-8 by default for Qcodo. But I think what might make the most sense, throughout the entire framework, is to utilize the MB_ extension for installations that are truly working with multibyte characters, and for those that aren't working with multibyte characters and that do not have the mb_ extension installed, it will still fall back gracefully and work (as long as you aren't working with multibyte characters).
That basically means that we will be having if function_exist() wrappers around any/ALL calls to strlen, strpos, str_replace, etc., calling the mb_ version if that function exists, and otherwise calling the standard PHP version of those functions if it doesn't.
I'd be happy to hear folks' thoughts.
The easiest solution could be to encapsulate all the potentially problematic string functions inside a new QString class, where string manipulation could be wrapped easily in only one place to avoid having checks all over the application code. Of course all the application (starting with Qcodo) should use that functions instead of the PHP native ones.
It's nothing more than an elegant patch, until more robust internationalization support comes from PHP itself. But it's the same idea of having a QDateTime class for managing that specific type.
Actually, it's a lot like how we do QApplication::HtmlEntities() since we're not really talking about using QString as a class to store each string value, we're merely talking about implementing a lot of QString methods as static methods to do things like strlen, etc.
I think it makes sense -- the only thing I'd want to do is make sure we're not going to take a big performance hit on this. Calls to things like the native strlen() are incredibly fast... and the framework (and pretty much all PHP apps) call string manipulation methods very often. If there's even a small perf hit, it can go a long way in greatly degrading the performance of a qcodo app, which is definitely something we do not want to do.
Thank you for helping out the Qcodo Development Framework by submitting a bug fix!
quality and consistency in the codebase, all submissions are reviewed before being committed to the core.
In order to ease the review process for the Qcodo administrators, please submit your codefix in one of the following formats: