My problem scenario is like this:
I have to migrate chatter data from a Japan org to my PROD org. The Japan org has all chatter data (CollaborationGroup, FeedItem & FeedComment) in Japanese language and I have tried the following way to export data but unable to insert multi-line data correctly:
1. Pulled a report for say (chatter group) with Encoding 'UTF-8' export type 'Excel or. csv', after exporting correctly I am able to dump that in unicode text and then .csv with unicode - UTF-08.
2. Pulled a Data-Export with checked - replace return carriage with spaces and then dumped into .csv with UTF-08 file format.

In both the method I am able to insert my multi-line text in one single line only and as the language is Japanese all inserted text looks more like a junk.

This is how it appears:

Correct Format




After Insertion

<入力する内容> ・コマーシャルオペレーション部からITへの依頼(現場ユーザーからの要望も含めます) ・ユーザーからの要望でコマーシャルオペレーションで自己完結した案件も含めます。 <対応の方法についてお願い> ・完成日の回答(予定)をお願いいたします。  -トラブル対応にて遅れる場合にもコメントをお願いいたします。 ・対応が完了しましたら対応済のコメントをお願いいたします。 ・ITからコマーシャルオペレーションで対応できると思われるものはその旨コメントください。 メールでの依頼を極力減らしこのグループへ投稿します(緊急対応の場合を除く)

Is there any way to through which I can insert my Japanese language multi-line text correctly Into my PROD org. Any help will be greatly appreciated.



  • Try without "replace return carriage with spaces" - it's pretty obvious it'll combine multiple lines into one :/ Reports might have same problem. Try exporting within Data Loader itself and check whether CSV file does contain multiple lines? – eyescream Jan 8 '14 at 14:52
  • Yes, I am presently exporting with this option 'unchecked'. And while extracting through data-loader these multi-line Japanese text got splitted into adjacent rows that will make it more worse. – Chirag Verma Jan 8 '14 at 17:36
  • It will appear to be split but the field boundaries should be determined by quote marks: "some value","text with newlines","another field's value". So it should import back OK. – eyescream Jan 8 '14 at 18:22
  • Right, using MSFT Excel to view CSV data can sometimes be misleading when dealing with UTF-8 and non A-Z,a-z,0-9. Notepad++ or even the browser using UTF-8 encoding gives a truer picture of the real bytes and placement of the line breaks – cropredy Jan 9 '14 at 3:06
  • Hey, I am taking an Data-Export again can you help me choose Encoding File format. I am only extracting Chatter Related data now that contains Japanese Character's. Previously I have selected UTF-08. – Chirag Verma Jan 9 '14 at 7:56

I found a way to load multi-line special character's data (say Japanese language) correctly as it was originally in their formatting. So what I have done is:
1. Uses a Data-Export feature to export all the records(having multi-line special charac) pertaining to any Standard/Custom objects with this CHECKBOX unchecked "Replace Return Carriage with Spaces".
2. Once the Data-Export is available, I just open the Exported .csv files directly by double clicking with Excel (ver. 2003 used in mine case); Once it is opened I do the required changes in various column for adding Id or updating without touching the columns with special character's and just saving in the same format by just clicking on save button.
3. Once the File is saved just load it through Data-Loader or Workbench & you will get your special character's data loaded in correct format. :)

In this way the Return Carriages also know as char(10) in Excel is preserved and the multi-line special character text got loaded correctly.

Also I have noticed that if the field in which we are inserting the multi-line special character is textarea then it will perfectly accept the Return Carriage or char(10) - said in Excel But if any-other field type like e.g. 'text' then it will not accept any new line character's.



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.