propose to add encoding attribute to data set about webpayments

[ianbjacobs]

@mountielee and I discussed further. I believe the concern is about what happens in this situation:

• payment request API is called in a context with character encoding A
• the data is handed to a web-based payment app that uses character encoding B

My assumption is that browsers manage this sort of translation from one encoding context to another. I would ask browser vendors to weigh in on whether they foresee any issues.

Ian

cc @ r12a

[ianbjacobs]

@mountielee,

I don't believe that payment request API specifies any encoding. I believe the surrounding context (e.g., HTML) is where the character set is defined, and one can specify different character encodings.

Am I missing something?
Ian

[mountielee]

at PaymentItems dictionary, product name can be included which are from
merchant can be encoded as non-unicode charset.
at PaymentAddress interface, languageCode is defined but that is not
enough, the merchant possibly will receive broken shipping address.

2016년 9월 23일 (금) 오전 10:53, ianbjacobs [email protected]님이 작성:

@mountielee https://github.com/mountielee,

I don't believe that payment request API specifies any encoding. I believe
the surrounding context (e.g., HTML) is where the character set is defined,
and one can specify different character encodings.

Am I missing something?
Ian

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#181 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADvzYLwwNcc_mXC78D2aSdg0vo6Rkd1sks5qs6GggaJpZM4KEy6W
.

[ianbjacobs]

@mountielee,

I think Unicode is a requirement on the Web, but different character encodings may be used within a <script> element; see https://www.w3.org/TR/html5/scripting-1.html#the-script-element

Ian

[mountielee]

@ianbjacobs

I know unicode is recommended.
but considering adaptation of web payments, we can not ignore page encoding.
I believe over 10 billions of peoples are influenced
and that is the reason browser vendors are sill supporting non-unicode encodings.

[ianbjacobs]

@mountielee,

I don't believe this is a discussion for this group. I believe HTML and JavaScript provide the necessary character encoding support. If they don't, the problem needs to be addressed there and not in our API.

Ian

[mountielee]

@ianbjacobs

if the merchant use this type of code
<script type="application/javascript" src="paymentrequest.js" charset="GBK"></script>

can we image payment app is able to handle well?

[rsolomakhin]

@mountielee Do you have an example website that uses non-unicode encoding and uses PaymentRequest? I'd like to see how it ends up working. I have a hunch that this will be largely a non-issue (or easily fixable).

[ianbjacobs]

@mountielee, web-based payment apps would handle encoding properly. We don't exercise any control over how native-based payment apps would work.

Ian

[mountielee]

@ianbjacobs
even well prepared web-based payment apps,
when they received payment request in broken characters, they have no way
to fix it.

web payment standard will encourage many small and non-technical merchants
using web payments.
when merchants receive broken shipping address (we already experienced this
case),
merchants have no way to fix it.

that is the reason charset attribute is added in script tag as part of
standard.

so if merchant is using non-unicode page encodings, with current
expectations, web payment will not work well.

2016년 9월 23일 (금) 오전 11:53, ianbjacobs [email protected]님이 작성:

@mountielee https://github.com/mountielee, web-based payment apps would
handle encoding properly. We don't exercise any control over how
native-based payment apps would work.

Ian

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#181 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADvzYAO_WrVIeHTneZUQqSwQKFwM_KbQks5qs6-PgaJpZM4KEy6W
.

[mountielee]

@ianbjacobs @rsolomakhin
I draw example sequence diagrams : https://goo.gl/alwYT7
the example merchant can be taobao.com or rakuten.co.jp those are biggest merchant in China and Japan.

[mountielee]

@ianbjacobs
this is the current solution I use : https://goo.gl/rC4f7T
in a single browser context, I don't know how to convert charsets in a context inside without server assistance

[rsolomakhin]

@mountielee Thank for the diagrams. That clarifies your question more. Can you stand up an actual server that calls PaymentRequest with non-unicode strings? See samples for example. These samples work in Chrome for Android.

[webpayments]

I will prepare sample after back to Korea at next week.

2016년 9월 23일 (금) 오후 1:41, Mountie Lee [email protected]님이 작성:

@ianbjacobs https://github.com/ianbjacobs
this is the current solution I use : https://goo.gl/rC4f7T
in a single browser context, I don't know how to convert charsets in a
context inside without server assistance

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#181 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APFrHMXp3LxcxGQ_5vexPcXP4BqDinqsks5qs8iDgaJpZM4KEy6W
.

[adrianba]

We've discussed this before. All strings in JavaScript are encoded in UTF-16. When resources are loaded over the network or from files the correct encoding must be specified. This allows the browser to convert from the encoded text into UTF-16. All browser APIs that operate on strings use UTF-16.

Needing to use a mechanism such as https://goo.gl/rC4f7T suggests that an incorrect charset is specified when data is read by the browser. If you don't indicate the correct encoding for data then it will never work correctly but properly tagged data will work automatically.

Here is how it works with the encode/decode steps shown: http://go4a.de/2cqTj46

[mountielee]

I have prepared EUC-KR encoded payment page.
https://devapi.paygate.net/orderforms/credit_cards_euckr.html
seams works well.
so the payment mediator convert encodings.

[ianbjacobs]

Closing as there has not been activity lately and in light of the response from Adrian.

[webpayments]

Je suis absent(e) du bureau jusqu'au 02/05/2018 Please kindly note my absence for the period mentioned above. You can reach Béatrice Cocozza at [phone] Remarque : ceci est une réponse automatique à votre message "Re: [w3c/webpayments] propose to add encoding attribute to data set (#181)" envoyé le 25/04/2018 15:08:31. C'est la seule notification que vous recevrez pendant l'absence de cette personne.

…

-------------------------------------------------------------------------------------------------------------------------------------------- Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. Le Groupement des Cartes Bancaires "CB" décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. This message and any attachments are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Groupement des Cartes bancaires "CB" shall not be liable for the message if altered, changed or falsified.