Resolution of the problem of long digital accuracy loss with leading 0 string loss 0 when PHP exports CSV

PHP-generated CSV can sometimes encounter two special cases:

1, the output of the field, contains an extra long number (18 digits) such as ID: 122121197410180016, even if the output field with "", or will be recognized as a number, and loss of precision, the back of the 4 will become 0, like this look 122121197410180000

2. In the output field, a numeric string containing leading 0 will be forced to discard the leading 0. For example: 01082151122, or 00001,00002, the system will be forced to recognize numbers such as 1082151122,1,2.

For the above problem, can only say that Excel is too evil, can not be solved by conventional means. There are 2 very return schemes:

1. You can manually set the field to text type and import it in Excel by importing text data, menu----data, but this is too difficult for the user to work with, so this method is not feasible.

2, with a more evil way to finish Excel, add a \ t tab at the end of the field, "\ T" is very special, in Excel is not to be displayed but he does exist, and then open the file, this field will be treated by default as a string. (Sequela is the field does have a \ t in the inside, if only to see that there is no problem, but also to import this thing into a heterogeneous system when \ t will cause unpredictable errors).

Well, weigh it myself, and I only think of these two options. The evil of Excel.

Resolution of the problem of long digital accuracy loss with leading 0 string loss 0 when PHP exports CSV