Skip to main content
Under Review

Unicode (non-Roman characters) support

Related products:Orders & Shipment Management
  • December 11, 2013
  • 31 replies
  • 7 views

We have a company store that sells to the world market. Countries in Asia (Chinese/Japanese/Korean) use 2-byte, non-Roman, unicode characters in their names and addresses. These address will have last characters filtered or altered when printed. It is annoying and risky to loss, not able to print them properly. As more and more companies sells internationally, it is good to prepare ShipStation ready for world markets.

31 replies

  • December 11, 2013
Currently, orders containing addresses with foreign characters such as ó, ƒ, Ê, _ and many others are being imported into shipstation in a garbled way. Shipstation actually does "support" most of the common international characters if you paste them in to the orders which is time-consuming and cumbersome. It just doesn't import csv files correctly as UTF-8. Basic foreign characters such as ones used in Latin America and Europe are very necessary for international shipping. Please fix this.

I agree with this. We are in Québec Canada with a lot of names and addresses containing "é,è,ê,à,etc." Please fix, it's not efficient to have double check all my addresses and client names.

  • February 5, 2014
I too have same problem. Russian characters are indicated as question marks. Please fix this.

  • August 5, 2014
Yes, please fix this! For example, Russian characters are shown as "???????" This is frustrating, time consuming, and often appears unprofessional since we have to cross out the ???? and hand-write the name.

  • July 23, 2015
This thread has become about two separate issues. It started with importing Latin characters that are not part of English. However, other people have complained about Cryllic characters appearing as question marks. I think that they may be different problems that both need fixing. I have the Cryllic alphabet issue. They import correctly from the marketplaces, but print as question marks (ie ??????) instead of the proper character. This is not ShipStation's fault, but due to a postal regulation that requires Latin characters on labels, so the problem applies equally to other non-Latin alphabets. My manual workaround is to first paste the original address into Internal Notes (to help recover from errors), then paste the address into Google translate and then paste the translated address into the ShipStation fields. Google Translate and other translation services have easy to use APIs. ShipStation should use one to automatically duplicate my manual process.

  • August 10, 2015
We need this as well. Foreign characters for Germany, Australia, Canada, and others.

  • March 6, 2016
Any updates here? We'll soon be on Amazon Japan. The manual correction of each address will be a time consuming process.

  • March 8, 2016
Hey @pricedright - After re-reading the original post ShipStation will accept UTF-8 character sets by default. You're able to select ANSI by selecting it in the menu when importing orders via CSV method. However there seems to be other character concerns here that we have yet to have the opportunity to research.

  • March 9, 2016
Thanks for the reply. Despite the OP's description of the problem, the real issue isn't which character set is supported by ShipStation, but which characters are supported by the postal service. As per the USPS Development Guide for their API (https://www.usps.com/business/web-tools-apis/general-api-developer-guide.htm), the only allowable charaters are from the ISO-8859-1 standard, which is essentially the first Unicode block of characters. It covers the alphabets of most Western European countries. That leaves out Cryllic, Hebrew, Arabic and most Asian languages. That's a real problem for those of us with broad international distribution. I think that my last post describes a good way to deal with the problem.

  • March 20, 2016
we want to be able to upload via mass load CSV file addresses in non English characters (Chinese, Mandarin, Japanese, etc')

  • June 16, 2016
This idea should be merged with "Support for common foreign characters".

  • June 16, 2016
This has been under review for nine months. Isn't it time to move forward with this bug?

  • August 24, 2016
Any update on this? we have trouble with exporting line items and it not exporting tildes and Chinese characters

When I was using the USPS or Stamps website for shipping, I was able to print western (Chinese) characters along side the English address. So I don't fully understand anyone saying that it is because of a Postal regulation.

  • November 7, 2016
We need to create labels with Japanese Kanji characters using DHL E-commerce and eventually FedEx. Currently ShipStation does not support these characters with their carrier integrations. DHL and FedEx support these characters through their APIs. EasyPost, Shippo, and ShipHawk all support these characters through their integrations. Is supporting this feature being actively worked on? If not, I will need to move my company to a new shipping solution.

  • November 26, 2016
I agree some sort of support for foreign character is essential for any business that sends international packages. Replacing foreign characters with ? is not acceptable. If it is necessary to replace foreign characters for some carriers this should be an optional toggle in shipstation, not done automatically on import.

  • March 9, 2017
So we use ZPL for our labels instead of the PDF option. We have the same problem with the ???. Generally, this would cause me to suspect that we need to install the appropriate font pack. However, if this is also happening with PDF labels then the issue is on SS Side. I'm only assuming they produce all the labels into ZPL then generate the PDF or Push the ZPL to customers like us that want it that way. Either way, getting this fixed would be super helpful. Having the shipping labels reflect the customers information when they enter it along side english in their own language helps to ensure faster, accurate deliveries with less returns.

  • November 13, 2017
I'm commenting on this, as shipstation used to print cyrillic characters just fine. When we first signed up, there was no issue with replacing non-latin letters with ??? This is very disruptive and it would be great if shipstation would revert to its original handling of these, which was flawless.

  • September 11, 2018
Hello there, we are in Canada, have the same issue but only with Purolator , not Canada Post

  • December 5, 2018
I ship only domestic orders but 90% of my customers are Latino/Hispanic and many have names with the Latin characters (á, é, í, ó, ú, ñ) and it looks really bad on my company not been able to print their names correctly. I have printed labels with all kind of services and ShopStatin is the only one not supporting this. The only reason I still use ShipStation is because of the mobile app.

  • May 23, 2019
This should also support foreign languages

  • September 30, 2019
Please, add a possibility to print labels for the addresses with hieroglyphs and other unicode symbols. At least for certain shipping companies like DHL that does support them.

  • November 5, 2019
We frequently receive orders from Korea, Japan and China, which means the customer's addresses are in character language rather than Latin characters. We will add an English translation and leave the customer's address alone when possible, but this often means the address is too long for the shipping label. Please add support for other character languages.

  • October 24, 2020
I'll add that I get an error message when trying to process a label that is entirely in Japanese characters that the address needs a "first and last name". I have to copy the email address as the company name to get it to print. And if I remember correctly, when printing packing slips for customs forms the Japanese characters show up as question marks.

  • October 27, 2020
Also adding Chinese language, Royal Mail supports chinese in their labels and it is such a waste of time having to translate all the orders manually