In XML and HTML you have some simple escaping rules that you have to follow. In XML the rules are even simpler, you just have to escape &, < and > which are presented as &amp; &lt; and &gt;

But some many people get this wrong, and we routinely get parcels addressed to Andrews &amp; Arnold Ltd, or as per the picture ANDREWS amp ARNOLD LTD. I think we have even seen Andrews &amp;amp; Arnold Ltd once.

It is not rocket science.

It had caused no end of issues for us having an & in the company name. BT took ages to get the XML ordering right as they injected the company name in XML they sent on to their Openreach division so orders went in but did not progress normally and nobody in BT knew why.

We even have fun trying to send OTA messages to mobile SIMs to set the operator name to A&A. It keeps coming up as A&amp;A on the phones.

Anyway, I now have UK company 08921585 which is &AMP;AMP; LTD.

But even UKPLC who do company formations insisted on emailing me about company &AMP; LTD, even in plain text emails!

I may have to set it up as a consultancy on XML.


  1. Presumably you have a son called Bobby too?

    1. I have a grandson called Bobby, and sadly my daughter did not name him appropriately, or even just make his middle name Tables.

  2. Did you put the ampersand in the company name deliberately to test for bugs? ;)

  3. Out of interest, what happens if HMRC or Companies House write to an incorrect/wrong company name? Are you legally OK to ignore such communications?

  4. Do you also get ones where the & has been ignored because it wasn't escaped (e.g. Andrews(space)(space)Arnold)? I see this frequently on card transactions for companies like M&S.

  5. I have perpetual problems ordering from websites since my (UK) address has the letter "ŷ" in it - very few websites seem to be able to cope, even international sites. Notably, SagePay's API only supports ISO-8859-1 (it ignores appropriate headers telling it the data is UTF-8 and blindly interprets it as ISO-8859-1. A lot of people who use SagePay don't seem to realise this and just shove UTF-8 data at SagePay, which obviously isn't going to work!). Google Checkout does get it right but always tells me that the seller doesn't support that address. Amazon (who you'd really expect to handle this stuff, as a big international company who must see all sorts of weird characters!) can't handle it either. Its not uncommon for me to receive a package that has "& # x 0 1 7 7;" in the address. (Interesting to note that putting "& # x 0 1 7 7;" into this comment without the spaces results in Blogger turning it into a "ŷ")!

    Still, its a good way for me to test websites that I'm implementing - pop in my own address and see if it works. :)

  6. It's the XML equivalent of Little Bobby Tables!

  7. PayPal's online postage system breaks if your posting to an address with non-ASCII characters (very common in Europe). It used to "work" but printed two random characters on the address label (faulty UTF conversion) but now it just gives up with "Not available" errors. The only way to get around it is to remove the characters and then manually add them back with a pen!

  8. Rather a long time after the event, but I just had the delight of using Aldi's feedback form. The plain text field there, converts, say:

    "Vintage cognac"


    &quot;Vintage cognac&quot;

    and then at the next iteration into:

    &amp;quot;Vintage cognac&amp;quot;

    My head hurts.

    (Incidentally, I had quite fun on this blog trying to get the right magic incantation in to get it to display how I wanted.)


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

TOTSCO 66 is guidance, optional

I feel I need to explain this. The TOTSCO call today, first I have been on, and wow! But a key point was TOTSCO bulletin 66, which is actual...