rfc:altmbstring

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
rfc:altmbstring [2009/07/27 08:01] – created moriyoshirfc:altmbstring [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Request for Comments: Alternative implementation of mbstring using ICU ====== ====== Request for Comments: Alternative implementation of mbstring using ICU ======
-  * Version: 1.0 +  * Version: 1.3 
-  * Date: 2009-07-27 +  * Date: 2014-02-05 
-  * Author: Moriyoshi Koizumi <moriyoshi@php.net> +  * Author: Yasuo Ohgaki <yohgaki@ohgaki.net> Moriyoshi Koizumi <moriyoshi@php.net> 
-  * Status: Under Discussion+  * Status: Declined
   * First Published at: http://wiki.php.net/rfc/altmbstring   * First Published at: http://wiki.php.net/rfc/altmbstring
 +
  
 ===== Introduction ===== ===== Introduction =====
Line 10: Line 11:
 This RFC discusses the alternative implementation of mbstring extension that in turn uses ICU instead of libmbfl. This RFC discusses the alternative implementation of mbstring extension that in turn uses ICU instead of libmbfl.
  
-===== Rationale =====+Note: This RFC is related to  
 +https://wiki.php.net/rfc/multibyte_char_handling This RFC is for long term resolution for multibyte character encoding related issues.
  
-Ever since its introduction in the very first version of PHP 4, mbstring extension has been controversial in a sense supposedly owing to the following reasons:+Note: This RFC is also address LGPL license issue used by current mbstring module. It is preferred to have alternative to mbstring that does not have license issue.
  
 +===== Rationale =====
 +
 +   * LGPL license - libmbfl(multibyte filter) and Oniguruma(Multibyte regular expression) is licensed by LGPL. Users that complie PHP statically may have license problem.
    * Lack of understanding -- It took long for those who don't use Unicode or other non-single-byte codesets to figure out how essential the functionality this extension covers, just until recently.    * Lack of understanding -- It took long for those who don't use Unicode or other non-single-byte codesets to figure out how essential the functionality this extension covers, just until recently.
    * Huge bundled libraries -- One of the bundled libraries, libmbfl, consists of a large set of Unicode-to-legacy charset mapping tables and vice versa. This may look redundant to those who aren't interested in manipulating multibyte strings.    * Huge bundled libraries -- One of the bundled libraries, libmbfl, consists of a large set of Unicode-to-legacy charset mapping tables and vice versa. This may look redundant to those who aren't interested in manipulating multibyte strings.
Line 55: Line 60:
    * mb_substr_count()    * mb_substr_count()
        
-==== Removed (deprecated) functions and reasons behind it ==== +==== Features to be implemented ==== 
-   * mb_check_encoding() -- Not that usable as it is advertised, period.  First of all, validation in terms of encoding is just as same as filtering through the converter supplied with the same value for the input and output encoding.  Thus just use mb_convert_encoding().  + 
-   * mb_convert_case() -- Use mb_strtoupper(), mb_strtolower() and mb_strtotitle() +   * All features that exist in mbstring will be ported to mbstring-ng unless there are technical difficulties.
-   * mb_convert_kana() -- This can't be standard-compliant. In addition, part of the functionality is already covered by Normalizer of intl extension, so we need to carefully consider what is actually needed here again. +
-   * mb_convert_variables() -- This can be implemented as a script. +
-   * mb_decode_mimeheader() and mb_encode_mimeheader() -- Non-standard compliancy.    +
-   * mb_decode_numericentity() -- Removed in favor of html_entity_decode(). +
-   * mb_encode_numericentity() -- Removed in favor of htmlentities() and htmlspecialchars(). +
-   * mb_encoding_aliases() -- Just unnecessary.    +
-   * mb_ereg_match() -- Use mb_ereg() +
-   * mb_ereg_search(), mb_ereg_search_getpos(), mb_ereg_search_getregs(), mb_ereg_search_init(), mb_ereg_search_pos(), mb_ereg_search_regs() and mb_ereg_search_setpos() -- I rarely heard a script that actively uses these functions. They involve an internal state that is not visible to users, and thus it most likely causes confusion when used across the function calls. Need to be reimplemented as a class.   +
-   * mb_eregi() -- Use mb_regex_options() and mb_ereg()    +
-   * mb_eregi_replace() -- I wonder why this function was added in the first place because giving 'i' option to mb_ereg_replace() works in the same way.    +
-   * mb_detect_order(), mb_get_info(), mb_http_input(), mb_http_output(), mb_language() and mb_substitute_character() --  ini_set() and ini_get() are your friends, I guess... +
-   * mb_regex_encoding() -- It is really confusing that the current mbstring allows two different encoding defaults for regex functions and the rest.  Those settings are unified in the alternative version and so this is no longer necessary. +
-   * mb_send_mail() -- The behavior of this function relies on the pseudo-locale setting called "mbstring.language" that supports just a limited set of possible locales. As not everyone can benefit from the function and most significant applications implement their own mail functions, I suppose this is no longer wanted. +
-   * mb_strrchr() -- Use mb_strrpos().    +
-   * mb_strrichr() -- Use mb_strripos().+
  
 ==== Known / remaining limitations and incompatibilities ==== ==== Known / remaining limitations and incompatibilities ====
Line 81: Line 71:
    * The group reference placeholders for mb_ereg_replace() is now $0, $1, $2... instead of \0, \1, \2.  This can be avoided if we don't use uregex_replaceAll() and implement our own.    * The group reference placeholders for mb_ereg_replace() is now $0, $1, $2... instead of \0, \1, \2.  This can be avoided if we don't use uregex_replaceAll() and implement our own.
    * ILP64  :-P     * ILP64  :-P 
 +
 +===== Proposal =====
 +
 +Introduce mbsgring-ng as EXPERIMENTAL module for testing compatibility against existing applications.
 +
 +===== Future Scope ====
 +
 +Compiling multibyte aware module by default is important for eliminating vulnerabilities related to character encoding. Compile mbstring-ng by default when it is ready. Replace mbstring by mstring-ng if it is possible.
 +
 +There will be a RFC for replacing mbstring by mbstring-ng, how it will be replaced, what to do with legacy mbstring, etc. Replacing module would be PHP 6 matter as it would break some applications.
 +
 +It is better to remove LGPLed code from 'must have' module. mbstring-ng shall remove this issue.
 +
 +**Note: Even when PHP supports Unicode internally, multibyte aware features/functions are needed to handle char encoding properly. Unicode does not solve all issues. There should be some module to handle it. Otherwise, default string functions must have encoding parameters and it would be  copy of mb_*() functions.**
 +
 +===== PHP Version =====
 +
 +PHP 5.6 and up
 +
 +===== VOTE =====
 +
 +VOTE: 2014/02/10 - 2014/02/17
 + 
 +<doodle title="Include mbstring-ng for PHP-5.6 as EXPERIMENTAL module" auth="yohgaki" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +
 +Thank you for voting!
 +
 +===== Reference =====
 +
 +  * https://wiki.php.net/rfc/multibyte_char_handling
  
 ===== Changelog ===== ===== Changelog =====
  
-   - 2009-07-27 Moriyoshi Koizumi: Initial+  - 2014-01-27 Yasuo Ohgaki: Updated to replace existing mbstring 
 +  - 2009-07-27 Moriyoshi Koizumi: Initial
rfc/altmbstring.1248681676.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools