Update column from Base64 to string (natively in SQL)












1















I've been trying to figure this out for two days now and would really appreciate some help. I've imported data from a csv where one field contained html data encoded in base64.



The idea is to loop over every row and run FROM_BASE64 on it.



How do I structure a query that:




  1. Loops over all lines

  2. Calls FRON_BASE64 for each line

  3. Runs UPDATE (or similar functionality) on that same row and column


Context: I'm running MariaDB (MySQL equivalent).



Thanks for any help!










share|improve this question





























    1















    I've been trying to figure this out for two days now and would really appreciate some help. I've imported data from a csv where one field contained html data encoded in base64.



    The idea is to loop over every row and run FROM_BASE64 on it.



    How do I structure a query that:




    1. Loops over all lines

    2. Calls FRON_BASE64 for each line

    3. Runs UPDATE (or similar functionality) on that same row and column


    Context: I'm running MariaDB (MySQL equivalent).



    Thanks for any help!










    share|improve this question



























      1












      1








      1








      I've been trying to figure this out for two days now and would really appreciate some help. I've imported data from a csv where one field contained html data encoded in base64.



      The idea is to loop over every row and run FROM_BASE64 on it.



      How do I structure a query that:




      1. Loops over all lines

      2. Calls FRON_BASE64 for each line

      3. Runs UPDATE (or similar functionality) on that same row and column


      Context: I'm running MariaDB (MySQL equivalent).



      Thanks for any help!










      share|improve this question
















      I've been trying to figure this out for two days now and would really appreciate some help. I've imported data from a csv where one field contained html data encoded in base64.



      The idea is to loop over every row and run FROM_BASE64 on it.



      How do I structure a query that:




      1. Loops over all lines

      2. Calls FRON_BASE64 for each line

      3. Runs UPDATE (or similar functionality) on that same row and column


      Context: I'm running MariaDB (MySQL equivalent).



      Thanks for any help!







      mysql sql mariadb






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 19 '18 at 18:24









      Bill Karwin

      377k63515670




      377k63515670










      asked Nov 19 '18 at 18:11









      MentorMentor

      472213




      472213
























          1 Answer
          1






          active

          oldest

          votes


















          1














          Typically base64 would be used for binary data. You probably shouldn't store the decoded data in the same column as the base64-coded string. If necessary you should ALTER TABLE to add a new column that is VARBINARY or BLOB type, to hold the binary data.



          ALTER TABLE MyTable ADD COLUMN BinaryField BLOB;


          You can then fill that column with an UPDATE statement:



          UPDATE MyTable SET BinaryField = FROM_BASE64(EncodedField);





          share|improve this answer
























          • Thank you for that! The current data type of the column is string (I'm importing into a table I didn't make and shouldn't alter). Would I cause issues with UPDATE MyTable SET BinaryField = FROM_BASE64(Binary Field) ;. In case I was unclear, I don't need the original Base64 string.

            – Mentor
            Nov 19 '18 at 18:37













          • Figured it out. update thetable set thecolumn = FROM_BASE64(thecolumn) did the trick. This was simpler than I anticipated.

            – Mentor
            Nov 19 '18 at 18:47











          • You might want to learn about character sets.

            – Bill Karwin
            Nov 19 '18 at 19:25











          • The Base64 column should be TEXT CHARACTER SET ascii COLLATE ascii_bin. (There are other options, but this is the most logical.)

            – Rick James
            Nov 20 '18 at 3:44











          • @RickJames, like I mentioned in my comment, the data was being imported into a database belonging to an existing codebase. The only reason the string was base64 encoded was to make it easier to store html in a csv file without causing syntax issues.

            – Mentor
            Nov 21 '18 at 10:22











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53380414%2fupdate-column-from-base64-to-string-natively-in-sql%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          Typically base64 would be used for binary data. You probably shouldn't store the decoded data in the same column as the base64-coded string. If necessary you should ALTER TABLE to add a new column that is VARBINARY or BLOB type, to hold the binary data.



          ALTER TABLE MyTable ADD COLUMN BinaryField BLOB;


          You can then fill that column with an UPDATE statement:



          UPDATE MyTable SET BinaryField = FROM_BASE64(EncodedField);





          share|improve this answer
























          • Thank you for that! The current data type of the column is string (I'm importing into a table I didn't make and shouldn't alter). Would I cause issues with UPDATE MyTable SET BinaryField = FROM_BASE64(Binary Field) ;. In case I was unclear, I don't need the original Base64 string.

            – Mentor
            Nov 19 '18 at 18:37













          • Figured it out. update thetable set thecolumn = FROM_BASE64(thecolumn) did the trick. This was simpler than I anticipated.

            – Mentor
            Nov 19 '18 at 18:47











          • You might want to learn about character sets.

            – Bill Karwin
            Nov 19 '18 at 19:25











          • The Base64 column should be TEXT CHARACTER SET ascii COLLATE ascii_bin. (There are other options, but this is the most logical.)

            – Rick James
            Nov 20 '18 at 3:44











          • @RickJames, like I mentioned in my comment, the data was being imported into a database belonging to an existing codebase. The only reason the string was base64 encoded was to make it easier to store html in a csv file without causing syntax issues.

            – Mentor
            Nov 21 '18 at 10:22
















          1














          Typically base64 would be used for binary data. You probably shouldn't store the decoded data in the same column as the base64-coded string. If necessary you should ALTER TABLE to add a new column that is VARBINARY or BLOB type, to hold the binary data.



          ALTER TABLE MyTable ADD COLUMN BinaryField BLOB;


          You can then fill that column with an UPDATE statement:



          UPDATE MyTable SET BinaryField = FROM_BASE64(EncodedField);





          share|improve this answer
























          • Thank you for that! The current data type of the column is string (I'm importing into a table I didn't make and shouldn't alter). Would I cause issues with UPDATE MyTable SET BinaryField = FROM_BASE64(Binary Field) ;. In case I was unclear, I don't need the original Base64 string.

            – Mentor
            Nov 19 '18 at 18:37













          • Figured it out. update thetable set thecolumn = FROM_BASE64(thecolumn) did the trick. This was simpler than I anticipated.

            – Mentor
            Nov 19 '18 at 18:47











          • You might want to learn about character sets.

            – Bill Karwin
            Nov 19 '18 at 19:25











          • The Base64 column should be TEXT CHARACTER SET ascii COLLATE ascii_bin. (There are other options, but this is the most logical.)

            – Rick James
            Nov 20 '18 at 3:44











          • @RickJames, like I mentioned in my comment, the data was being imported into a database belonging to an existing codebase. The only reason the string was base64 encoded was to make it easier to store html in a csv file without causing syntax issues.

            – Mentor
            Nov 21 '18 at 10:22














          1












          1








          1







          Typically base64 would be used for binary data. You probably shouldn't store the decoded data in the same column as the base64-coded string. If necessary you should ALTER TABLE to add a new column that is VARBINARY or BLOB type, to hold the binary data.



          ALTER TABLE MyTable ADD COLUMN BinaryField BLOB;


          You can then fill that column with an UPDATE statement:



          UPDATE MyTable SET BinaryField = FROM_BASE64(EncodedField);





          share|improve this answer













          Typically base64 would be used for binary data. You probably shouldn't store the decoded data in the same column as the base64-coded string. If necessary you should ALTER TABLE to add a new column that is VARBINARY or BLOB type, to hold the binary data.



          ALTER TABLE MyTable ADD COLUMN BinaryField BLOB;


          You can then fill that column with an UPDATE statement:



          UPDATE MyTable SET BinaryField = FROM_BASE64(EncodedField);






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 19 '18 at 18:27









          Bill KarwinBill Karwin

          377k63515670




          377k63515670













          • Thank you for that! The current data type of the column is string (I'm importing into a table I didn't make and shouldn't alter). Would I cause issues with UPDATE MyTable SET BinaryField = FROM_BASE64(Binary Field) ;. In case I was unclear, I don't need the original Base64 string.

            – Mentor
            Nov 19 '18 at 18:37













          • Figured it out. update thetable set thecolumn = FROM_BASE64(thecolumn) did the trick. This was simpler than I anticipated.

            – Mentor
            Nov 19 '18 at 18:47











          • You might want to learn about character sets.

            – Bill Karwin
            Nov 19 '18 at 19:25











          • The Base64 column should be TEXT CHARACTER SET ascii COLLATE ascii_bin. (There are other options, but this is the most logical.)

            – Rick James
            Nov 20 '18 at 3:44











          • @RickJames, like I mentioned in my comment, the data was being imported into a database belonging to an existing codebase. The only reason the string was base64 encoded was to make it easier to store html in a csv file without causing syntax issues.

            – Mentor
            Nov 21 '18 at 10:22



















          • Thank you for that! The current data type of the column is string (I'm importing into a table I didn't make and shouldn't alter). Would I cause issues with UPDATE MyTable SET BinaryField = FROM_BASE64(Binary Field) ;. In case I was unclear, I don't need the original Base64 string.

            – Mentor
            Nov 19 '18 at 18:37













          • Figured it out. update thetable set thecolumn = FROM_BASE64(thecolumn) did the trick. This was simpler than I anticipated.

            – Mentor
            Nov 19 '18 at 18:47











          • You might want to learn about character sets.

            – Bill Karwin
            Nov 19 '18 at 19:25











          • The Base64 column should be TEXT CHARACTER SET ascii COLLATE ascii_bin. (There are other options, but this is the most logical.)

            – Rick James
            Nov 20 '18 at 3:44











          • @RickJames, like I mentioned in my comment, the data was being imported into a database belonging to an existing codebase. The only reason the string was base64 encoded was to make it easier to store html in a csv file without causing syntax issues.

            – Mentor
            Nov 21 '18 at 10:22

















          Thank you for that! The current data type of the column is string (I'm importing into a table I didn't make and shouldn't alter). Would I cause issues with UPDATE MyTable SET BinaryField = FROM_BASE64(Binary Field) ;. In case I was unclear, I don't need the original Base64 string.

          – Mentor
          Nov 19 '18 at 18:37







          Thank you for that! The current data type of the column is string (I'm importing into a table I didn't make and shouldn't alter). Would I cause issues with UPDATE MyTable SET BinaryField = FROM_BASE64(Binary Field) ;. In case I was unclear, I don't need the original Base64 string.

          – Mentor
          Nov 19 '18 at 18:37















          Figured it out. update thetable set thecolumn = FROM_BASE64(thecolumn) did the trick. This was simpler than I anticipated.

          – Mentor
          Nov 19 '18 at 18:47





          Figured it out. update thetable set thecolumn = FROM_BASE64(thecolumn) did the trick. This was simpler than I anticipated.

          – Mentor
          Nov 19 '18 at 18:47













          You might want to learn about character sets.

          – Bill Karwin
          Nov 19 '18 at 19:25





          You might want to learn about character sets.

          – Bill Karwin
          Nov 19 '18 at 19:25













          The Base64 column should be TEXT CHARACTER SET ascii COLLATE ascii_bin. (There are other options, but this is the most logical.)

          – Rick James
          Nov 20 '18 at 3:44





          The Base64 column should be TEXT CHARACTER SET ascii COLLATE ascii_bin. (There are other options, but this is the most logical.)

          – Rick James
          Nov 20 '18 at 3:44













          @RickJames, like I mentioned in my comment, the data was being imported into a database belonging to an existing codebase. The only reason the string was base64 encoded was to make it easier to store html in a csv file without causing syntax issues.

          – Mentor
          Nov 21 '18 at 10:22





          @RickJames, like I mentioned in my comment, the data was being imported into a database belonging to an existing codebase. The only reason the string was base64 encoded was to make it easier to store html in a csv file without causing syntax issues.

          – Mentor
          Nov 21 '18 at 10:22




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53380414%2fupdate-column-from-base64-to-string-natively-in-sql%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          鏡平學校

          ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

          Why https connections are so slow when debugging (stepping over) in Java?