Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output of toXML() for <real>s is locale-dependent and causes creation of invalid PList-XML #67

Open
stefanschramm opened this issue May 31, 2021 · 4 comments · May be fixed by #68
Open
Assignees
Labels

Comments

@stefanschramm
Copy link

Describe the bug
When using a locale that uses commas (,) instead of points (.) as decimal delimiter, the output of CFPropertyList::toXML() uses this charater for <real>s which is invalid PList-Data. The cause is probably some implicit toString conversion that will use the current locale.

To Reproduce
Execute this script:

<?php
use CFPropertyList\CFPropertyList;
require_once('vendor/autoload.php');
$example = <<<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict><key>ExampleReal</key><real>1.5</real></dict></plist>
EOF;
setlocale(LC_ALL, 'de_DE.UTF-8');
$plist = new CFPropertyList();
$plist->parse($example);
echo $plist->toXML();

It's output will be:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict><key>ExampleReal</key><real>1,5</real></dict></plist>

Expected behavior
This output:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict><key>ExampleReal</key><real>1.5</real></dict></plist>

(1.5 instead of 1,5)

Desktop

  • Linux 5.4, PHP 7.4.3 using CLI, Composer-Package rodneyrehm/plist v2.0.2
@btry btry added the bug label May 31, 2021
@btry
Copy link
Collaborator

btry commented Jun 3, 2021

Hi

I reproduce. The problem is caused by the use of the function floatval() which outputs a float in a format dependent on your locale.

@btry btry linked a pull request Jun 3, 2021 that will close this issue
@btry
Copy link
Collaborator

btry commented Jun 3, 2021

Please test the patch above, and feedback.

@btry btry self-assigned this Jun 3, 2021
@stefanschramm
Copy link
Author

The patch adds the dependency to install the php-intl-Extension.

Using bigger numbers like 1234.5 will add thousands-separators: 1,234.5. Adding $formatter->setAttribute(\NumberFormatter::GROUPING_USED, false); solves this for me.

@btry
Copy link
Collaborator

btry commented Jun 4, 2021

Hi

Yes, you're right. I add this extra attribute to the PR.

However I cannot merge the fix right now : I need to add an unit test for your issue, and migrate test environment to github actions. I need some time to do this, merge and build a new release.

EDIT : I added the dependency to php-intl. I think it is better to rely on NumberFormatter instead of a filthy string manipulation, which may break for some foreign language.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants