<https://github.com/nicolas-grekas/Patchwork-UTF8>. > > > compiling PHP with mbstring or iconv is much easier and is not that > difficult. So, just abstracting mbstring and iconv is probably not enough > to include an abstraction on top of them. >
I should add that you should consider several sub-packages inside the code : - the Normalizer class - the PHP based grapheme_* functions - the PHP based mbstring functions - the PHP based iconv functions - the PHP based utf8_(en|de)code - the Patchwork\Utf8 class They are all independent and you may be interested in only some of them. For the mbstring, iconv and utf8_(en|de)code functions, these are not interesting when you can compile php. They instead provide a compatibility guarantee that some important utf-8 functions will work even on shared hosts. I don't know if that's common today, but what I know is that many open source projects (mediawiki, phpbb, etc) all have this concern. Is it for Symfony to solve ? It's up to you to decide of course. Same reasoning for grapheme_* functions, with the intl compilation difficulties added. For the Normalizer class, I personally use it on every input data : my applications always expect UTF-8 submissions, but normalized as form C. That's where Normalizer is mandatory. Should Symfony utf-8 apps do the same ? Then for the Patchwork\Utf8 class, please look at it and tell me how useful you think it is ! Many thanks, Nicolas -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
