9

Arabic user data that was captured with our web-to-lead form occasionally ends up Mojibake in our lead table. A user would type something like:

الإعلان العالمى لحقوق الإنسان

When we retrieve the message from the database, it reads:

الإعلان العالمى لحقوق الإنسان

The form is in an embedded iframe page with these tags:

<!DOCTYPE HTML>
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="content-type" />

    <!-- other header elements -->

  </head>

  <body>
    <form accept-charset="utf-8" action="https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8" method="post">

   <!-- other body elements -->

  </body>

</html>

After first noticing the problem I added the accept-charset attribute to the form tag. Is there anything more I can do in the page markup that can prevent the problem?

Since the character scramble only happens occasionally, what is the best way to try and replicate / isolate the problem? We have several triggers running after a lead insert and logging all web-to-lead activity generate a fantastic amount of raw data to wade through to try and spot the occasional culprit. Not sure what to look for anyway. User agent signature? Characters falling outside/inside a certain unicode range?

Thanks!

Improve this question
2
  • The string الإع… is the Arabic input when it has been represented as UTF-8 with BOM and the bytes of that representation are then misinterpreted as if they were windows-1252 encoded data. From the outside, we cannot really tell where this problem is generated. It is possible that the data is being viewed under conditions that enforce windows-1252 interpretation, e.g. when HTTP specify it in a Content-Type header, overriding the meta tag.
    – Jukka K. Korpela
    Apr 29, 2014 at 7:32
  • @JukkaK.Korpela with "It is possible that the data is being viewed ..." do you mean the data is not stored as UTF-8 in salesforce and then when we view the case record in a browser the transcoding takes place? This is definitely not the case. I can see properly encoded Arabic and this gibberish on the same case inside salesforce.
    – JannieT
    May 6, 2014 at 9:12

1 Answer 1

Reset to default
1

JannieT, I think the issue may be due to the character encoding specified on the pages where your Web-to-Lead form is placed. For example, the same Web-to-Lead form on a page that uses UTF-8 encoding will produce entirely different data in your org when placed on a page using ISO 8859-1 encoding.

Can you see whether this is the case with the pages that are producing problematic leads? Take a closer look at the meta elements on your W2L pages, and check to see whether charset is being set to UTF-8.

Improve this answer
3
  • Thanks Marty. There is just one page that is producing the problem and I have posted the code. Can you see a problem with it?
    – JannieT
    May 29, 2014 at 14:04
  • Hello, JannieT, are you referring to the code sample you wrote in your original question? Is that the only page that's being embedded in all places where you've deployed the Web-to-Lead form?
    – Marty C.
    May 29, 2014 at 18:00
  • Marty, yes and yes.
    – JannieT
    May 30, 2014 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .