When exporting CSV files in php, the loss of super-long numeric precision and the loss of leading 0 strings are solved.

When exporting CSV files in php, the loss of super-long numeric precision and the loss of leading 0 strings solve the problem that CSV files generated in php sometimes encounter two special situations:

1. the output field contains an extra-long number (18-digit number) such as ID card: 122121197410180016. even if "" is added to the output field, it is still recognized as a number and the precision is lost, the four digits that follow will change to 0, as shown in the following figure: 122121197410180000

2. if the output field contains a leading 0 numeric string, the leading 0 is forcibly dropped. For example, 01082151122, or, the system will forcibly recognize numbers like 1082153162, 1, and 2.

To solve the problem above, we can only say that excel is too evil to be solved by conventional means. There are two sub-solution:

1. you can use menu> Data> Import text data in excel to manually set the field to the text type and then import it. However, this operation is too difficult for users, therefore, this method is not feasible.

2. use a more evil way to get an excel file. add a \ t tab at the end of the field. "\ t" is very special. it won't be displayed in excel, but it does exist, when the file is opened, this field will be processed as a string by default. (The sequent effect is that there is indeed a \ t in the field. if you just use it to see it, there is no problem, however, importing this item into a heterogeneous system may cause unexpected errors ).

Alas, let's weigh it by myself. I only think of these two solutions. Excel.