Rather an unexpected new year greeting for me :)
Simply I don't see much need for such feature. Why do you need it? There are already enough materials to make an equivalent by your own.

Sorry for unexpected greeting. Akemashite omedetou.

Yes, I am working on New Year's day .. and guess what I was coding ... an mb version of str_pad ...

I agree that I could roll my own function, and indeed I have done so using mb_strwidth (though it doesn't work perfectly and I can't figure out why. Something to do with the fact that the string contains both full-width and half-width characters I suspect; need more debugging).

But then again the same thing could be said about the str_pad function. Why was it created? All the needed functionality for a user to create his own version of str_pad already existed, so there really wasn't a "need" to create the str_pad function ... But I guess str_pad was such a useful function to have and was being used by enough people that a standard PHP function was created.

The basic reason for asking is simply that str_pad exists but does not work with multibyte strings. I know the developpers probably have a lot more important things to work on, so all I ask is that it be put on a TO-DO list, even if at the bottom :)

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

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!

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.

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

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

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>