-1

(Same as https://github.com/docker-library/php/issues/1301 )

The results of running the following script were different between php:7.4.29-fpm-alpine and php:7.4.28-fpm-alpine.

<?php

$fmt = new \NumberFormatter('JA_JP', \NumberFormatter::CURRENCY);
$formatString = $fmt->formatCurrency(0, 'JPY');

var_dump($formatString);

Result

  • php:7.4.28-fpm-alpine (I expects)

    string(4) "¥0"
    
  • php:7.4.29-fpm-alpine

    string(3) "¥0"
    

(My) problem

Is there any way to get the results in php:7.4.29-fpm-alpine to be what they were in php:7.4.28-fpm-alpine ? (Is there a workaround?)

Way to reproduce

see https://github.com/sogaoh/reproduce-incompatibility-of-format-currency (README.md)

Remarks

( unconfirmed ) I'm guessing that there is a similar problem between

  • 8.0.19 and 8.0.18
  • 8.1.6 and 8.1.5
Sammitch
  • 30,782
  • 7
  • 50
  • 77
sogaoh
  • 34
  • 3
  • Can you explain in words what the difference in output is? I can see the one is 4 bytes and the other is 3, but there doesn't seem to actually be a space there, just a different version of the Yen symbol? Also, this doesn't seem to be a change in PHP itself, but some other OS component - perhaps as mentioned on the Github issue something in the ICU library: https://3v4l.org/82uqr – IMSoP May 26 '22 at 22:45

2 Answers2

1

The difference between the two is that the .28 version uses \uffe5 'Fullwidth Yen Sign, and the .29 version uses \u00a5 'Yen Sign.

As noted in the github issue comment, it's likely a change in the underlying ICU library between builds of the image, as opposed to an issue in the image, Alpine, or PHP themselves. As an interim fix you could use a modified image that installs a pinned version of ICU, but YMMV.

Alternatively you could shim in a simple replacement like:

str_replace("\xc2\xa5", "\xef\xbf\xa5", $formatter_output);

Though the issue itself is fairly cosmetic, and IMO the original use of a fullwidth glyph for the currency symbol was the more questionable option.

Sammitch
  • 30,782
  • 7
  • 50
  • 77