Due to the company’s architecture, the front-end request needs to be forwarded through NodeJs interface and then returned to the browser. When the proxy request was made to the exported Excel interface, garbled characters were found in the exported data to the browser, which was finally found to be a coding problem.

Even if Java back-end has been done to the data processing, after the node interface request response document flow code was revised, before thinking about should be one-to-one request and response approach to obtain the original data of the psychological set, should not respond to the response for processing, but what should directly get back. Has not been to the direction of the coding problem to think about, some of the toss and toss and even use three different request way or return garbled data, can not help but begin to doubt their own in the past few years the front end is not in vain, is also suitable for development? Maybe it’s time to switch to food delivery…

Error train of thought:

  1. Use Postman to request the backend interface directly, without passing through nodeJs. Copy the curl command code generated after the postman request, open the command line tool to paste it, and add -o test_java. XLS at the end of the press enter, save the requested file stream as Excel and open it to check whether there is a problem with the Java backend interface itself. I opened it up here and found that the data was neatly arranged…

  2. Click Copy as cURL. Add -o test_nodejs. XLS at the end of the command to open the file and check for garble. The problem is NodeJs requests to the back-end interface

  3. If the files are found to be ok after the above two steps are opened, then there is a problem with the front-end client’s processing code for the file stream

Here is my client code, no problem…

Client code

Create the A tag and simulate the click event to download the Excel file

   if (isBlob(res.data)) {
      const filename = decodeURIComponent(
        headers['content-disposition'].match(/(filename=(.*))/) [2]);// The server needs to set Content-disposition in the response header
      const blob = new Blob([res.data], {
        type: 'application/octet-stream'});const linkNode = document.createElement('a');
      linkNode.download = filename;
      linkNode.style.display = 'none';
      linkNode.href = URL.createObjectURL(blob);
      document.body.appendChild(linkNode);
      linkNode.click();

      URL.revokeObjectURL(linkNode.href);
      document.body.removeChild(linkNode);
    } else {
      // Failed to export
    }
Copy the code

NodeJs server-side code

NodeJs adopts the egg framework, and the following three request methods all return garbled codes when the encoding is not set in the early stage. If the problem point is found later, a Buffer cache can be successfully obtained after modification, which can be directly returned to the browser. I’m using axios, but I’m just familiar with the library. There may be inconsistent requests and responses in different environments. Here I’ll share all three requests with you

        const axios = require('axios');
        const rp = require('request-promise');

      $curl = $curl = $curl = $curl = $curl * dataType explicitly tells HttpClient to process the returned response body in text format such as XML, set it to 'JSON', and process the returned response body in JSON lattice * without setting dataType: By default HttpClient does nothing and returns Buffer */ directly
      const result = await ctx.curl(requestURI, {
        method: 'POST'.timeout: 60000.data: JSON.stringify(body),
      });
      ctx.set({
        'Access-Control-Expose-Headers': 'Content-Disposition'.'content-disposition': result.headers['content-disposition']}); ctx.body = result.data;ResponseType: 'arrayBuffer ', responseEncoding: 'binary' */
      const result = await axios({
        method: 'POST',
        url,
        params: queryParams,
        data: body,
        responseType: 'arraybuffer'.responseEncoding: 'binary'}); ctx.set({'Access-Control-Expose-Headers': 'Content-Disposition'.'content-disposition': result.headers['content-disposition']}); ctx.body = result.data;/** * Request -promise Void, * set encoding to binary (encoding is binary) * address: https://stackoverflow.com/questions/48752822/request-promise-download-pdf-file/48753392#48753392 */
      const result = await rp({
        method: 'POST'.uri: requestURI,
        body: JSON.stringify(body),
        resolveWithFullResponse: true.encoding: null}); ctx.set({'Access-Control-Expose-Headers': 'Content-Disposition'.'content-disposition': result.headers['content-disposition']}); ctx.body = result.body;Copy the code

conclusion

  • The early stage has been set to their own not to back-end data to do second processing of the way of thinking limited their play, in the emergence of garbled code after the first thought is the request library to do some processing of the data. How about another one? Helpless or garbled…
  • For THE HTTP protocol, the lack of understanding of the request header and response header led to the scope of thinking when the request went wrong. After consulting other colleagues in the company, I was confused and just wrote in order to need to write without knowing why. Knowing why and not knowing why
  • Processing data flow is still rare, and the front-end knowledge of handling response bodies in different scenarios also needs to be completed

This article is to commemorate the problems encountered in the development of Excel function export

The way ahead is so long without ending, yet high and low I’ll search with my will unbending.