Req #21317 [Ana->Sus]: Add mb_pad() counterpart

Edit report at https://bugs.php.net/bug.php?id=21317&edit=1 ID: 21317 Updated by: cmb@php.net Reported by: jc at mega-bucks dot co dot jp Summary: Add mb_pad() counterpart -Status: Analyzed +Status: Suspended Type: Feature/Change Request Package: mbstring related Operating System: * PHP Version: * Block user comment: N Private report: N New Comment: This feature request should be forwarded to the internals mailing list[1]; otherwise it is likely to be unimplemented for another 17 years. For the time being, I'm suspending this ticket. [1] <https://www.php.net/mailing-lists.php#internals> Previous Comments: ------------------------------------------------------------------------ [2015-12-16 11:15:25] nadim dot attari at gmail dot com I needed str_pad while exporting a fixed-length CSV file with accentuated characters and it went wrong. I'm using this solution for the time being: https://gist.github.com/nebiros/226350 It would be nice to have an mb_str_pad and I vote for this. Nadim Attari ------------------------------------------------------------------------ [2015-07-30 15:24:15] ignacio at gm2dev dot com Is this function going to be added to the spec? There are a couple possible solutions in the PHP manual http://php.net/manual/en/ref.mbstring.php#90611 ------------------------------------------------------------------------ [2010-06-23 10:15:33] PhoneixSegovia at gmail dot com I vote to this. I think that we must have a multibyte str_pad as other string function. This make support for multilanguage applications. About the width to pad problem, I think that we need to get the same behaviour than str_pad. The string to pad is more an "array of chars" to pad not a fixed string to pad. ------------------------------------------------------------------------ [2003-01-01 05:23:11] jc at mega-bucks dot co dot jp Great! Please update the bug report when you have implemented a solution so that I can download it and try it out! (as I said, my solution isn't working in all cases). As for your question, as I see it, the only way that this could happen where if the user supplied a double-width character for the padding string *and* we assume that the pad_length is a count in single-width. But I don't think the problem your present is any different that the problem that str_pad has when passed arguments like this: str_pad("1", 2, "--"); In this example adding the pad string would produce a string longer than is requested. I just tested this code out and PHP gives "1-", which in my opinion is a bug ... I was going to say that the mb version should adopt the same behaviour but since the str_pad behaviour seems to be wrong (in my poor opinion) I am not sure what the correct behaviour should be. I guess one way would be to add a parameter, pad_with_half_width_space, that would let the user decide wether to pad with a half-width space or not if the input string lentgh cannot be divided by the length of the string to pad with. Or, you could say that the behaviour of the function is to *always* pad with half-width spaces by default. But then we have the problem of what to do if the user wants to pad a string of length 2, to be length 5 and the padding character is 2 wide ... we can pad up to length 4, but what to do with the remaining half-width, (pad with a half space? Do nothing?) I can't think of any answer that is "correct", so suggest putting your foot down, defining the what the behaviour will be in those cases and if you feel generous adding parameter to the function to change the default behaviour. Thanks! ------------------------------------------------------------------------ [2003-01-01 04:57:14] moriyoshi@php.net Okay, let's keep this open. I'll implement it in my spare time. Yet I have a quetion: what if the length(width) of the input string cannot be divided by the length of the string to pad with??? Should the remainder be padded with han-kaku spaces? Anyway, akemashite omedetou. Moriyoshi ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=21317 -- Edit this bug report at https://bugs.php.net/bug.php?id=21317&edit=1