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:

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

    <!-- other header elements -->


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

   <!-- other body elements -->



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?


  • 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 '14 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 '14 at 9:12

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.

  • 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 '14 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 '14 at 18:00
  • Marty, yes and yes. – JannieT May 30 '14 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.