I'm attempting to save an image base64'ed with nodejs in a raw format to an ODT file for display in OpenOffice Writer.
The spec was not very clear, but I found an example. However, when I post the following base64'd image (that looks fine in html), I get a "Read-error" in OpenOffice and the image does not display.
The spec says that it uses rfc2045, but that spec is not very specific (unless I'm missing something).
Here's what I have:
<text:p text:style-name="qr-wrapper">
<draw:frame draw:name="img1" svg:width="150.0pt" svg:height="150.0pt">
<draw:image xlink:href="Pictures/0.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
<office:binary-data>
iVBORw0KGgoAAAANSUhEUgAAAJYAAACWCAIAAACzY+a1AAAABGdBTUEAA1teXP8meAAABjpJREFUeAHtm92OHTcMg7tF3/+VtwlaBB+8Q0Eee46HAHOlkSlaJmMLm5+v7+/vv/LLWYG/nZtP778ViIX2vw9iYSy0V8D+ALmFsdBeAfsD5BbGQnsF7A+QWxgL7RWwP0BuYSy0V8D+ALmFsdBeAfsD5BbGQnsF7A/wz40TfH193aiqSzp/87xrX+5FTubrbv9bZW0H38HM9vCLMw9pR9hXY2Lhq+3pNBcLOyq9GnNnFvJAN97uP+W7Zgl7UJwK08n/abgIyFPALpdUz5fgn8ncwp+amGVioZlhP9uNhT81McuszkIet/Omr8wMVct9Oxj2rOIOZ6dWYVSfCl/kcwsLcTyWYqGHT0WXsbAQx2Np5yx84sScSeTnLGFMPPOsZUw8851a4g/GuYUHxd+zdSzco+NBllh4UPw9W79xFnI+qZlETEcJ8rCWefJ0MMQfjHMLD4q/Z+tYuEfHgyyx8KD4e7beOQvVXJntVPHMzifi2QP5FYZ4YlhLDOMOhvjFOLdwUcDz5bHwvAeLHcTCRQHPl6/OQs6JXachZ2eudPDkUfhOXp2RtQrzUD638CFhP0cbCz+n9UM7xcKHhP0c7ReHxOe2LXfqzBXVNmsVptz8/8VdPJ29FjG5hYsCni+Phec9WOwgFi4KeL585yzk/ODJ1ExS+E4tMbti9jPbM/Ednl09/+LJLdwo5hmqWHhG9427xsKNYp6hujMLO299B8MTKzzzxKuYM0lhyEn8Sl7tpfKdfVXtkM8tHATx+4yFfp4NHcfCQRC/zzuzcPaUnDGztZwZs7Ud/Gxv7Ie1zKt9iSemU0v8EOcWDoL4fcZCP8+GjmPhIIjf551ZyDed77jKU5UOhnjGs7XEk4c9M088MSrPWhV3ajsYxf8rn1tYiOOxFAs9fCq6jIWFOB5LO/8dKeeHOj0xnRlADDlVnvzEq5g8rN2VV5yqnxv53MIbor2rJBa+y48b3cTCG6K9q2R1FnbeemJ4epXnHJrFs5b8zJOTcQezi3OWh30OcW7hIIjfZyz082zoOBYOgvh9rv4ZKU/M9515FavZQx6FUZyztcSTU+07iycna2f5yTPEuYWDIH6fsdDPs6HjWDgI4ve5cxZ2Ts95oPCdOUEMOVfyqp9OXvXAWmKYVz0TU8S5hYU4Hkux0MOnostYWIjjsbTzz0hnT8wZwFo1M4hRsaplfnbfWbzqjXlysjdimnFuYVOo98Ji4Xu9aXYWC5tCvRd25+dCnoZvOvMqnn33yd+p3YXfxUMdZjlZW8S5hYU4Hkux0MOnostYWIjjsXTn50L1pjPfOT3xnHOdPPlZyzxjxclahenk1V7MPxTnFj4k7OdoY+HntH5op1j4kLCfo139uZCdcmYwz3nDPGNVS4ziYa3CkKcTK07mydPZd6WWew1xbuEgiN9nLPTzbOg4Fg6C+H2uzsLO+04MZ8auvFJd8Ss886xlfjZW51U8xCvMkM8tHATx+4yFfp4NHcfCQRC/z9VZ+MSJOYc4G5jnvsQw34k7nMR09iKePbC2g2FtEecWFuJ4LMVCD5+KLmNhIY7H0urfF+46JecEOTkzOhjWqpg8jLkXY8VDDHmIZ554hWG+GecWNoV6LywWvtebZmexsCnUe2F3ZiFPw7ee+U7cmQ0Ko/LcV/U2W6vwip89MJ7Fs7aIcwsLcTyWYqGHT0WXsbAQx2NpdRbylGpmELNrHuziYW+duHNG8ig8+yeGefIUcW5hIY7HUiz08KnoMhYW4ngs7ZyFu06sZoPKc98OhngVr/Cw9gn+gTO3cBDE7zMW+nk2dBwLB0H8Pt84C6mimivMq5+liCEn8bMY1pKTPMSofKeWmCLOLSzE8ViKhR4+FV3GwkIcj6Wds5AzYOX0T/BwJqneuC/xzLNWYZgnnjExip/4Is4tLMTxWIqFHj4VXcbCQhyPpdVZyDf91InZQ2eurODVGRUn86p2MZ9buCjg+fJYeN6DxQ5i4aKA58vf+P8Lz6ti1UFuoZVdV83GwitVrHKx0Mquq2Zj4ZUqVrlYaGXXVbOx8EoVq1wstLLrqtlYeKWKVS4WWtl11WwsvFLFKhcLrey6ajYWXqlilYuFVnZdNRsLr1SxysVCK7uumo2FV6pY5f4FHaQ4Pt0WyyMAAAAASUVORK5CYII=
</office:binary-data>
</draw:image>
</draw:frame>
</text:p>
I could use a base64 conversion library, like for instance this nodejs one. What format is expected?
Well, folks the answer is as follows:
<text:p text:style-name="qr-wrapper">
<draw:frame draw:name="img1" svg:width="150.0pt" svg:height="150.0pt">
<draw:image xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
<office:binary-data>
iVBORw0KGgoAAAANSUhEUgAAAJYAAACWCAIAAACzY+a1AAAABGdBTUEAA1teXP8meAAABjpJREFUeAHtm92OHTcMg7tF3/+VtwlaBB+8Q0Eee46HAHOlkSlaJmMLm5+v7+/vv/LLWYG/nZtP778ViIX2vw9iYSy0V8D+ALmFsdBeAfsD5BbGQnsF7A+QWxgL7RWwP0BuYSy0V8D+ALmFsdBeAfsD5BbGQnsF7A/wz40TfH193aiqSzp/87xrX+5FTubrbv9bZW0H38HM9vCLMw9pR9hXY2Lhq+3pNBcLOyq9GnNnFvJAN97uP+W7Zgl7UJwK08n/abgIyFPALpdUz5fgn8ncwp+amGVioZlhP9uNhT81McuszkIet/Omr8wMVct9Oxj2rOIOZ6dWYVSfCl/kcwsLcTyWYqGHT0WXsbAQx2Np5yx84sScSeTnLGFMPPOsZUw8851a4g/GuYUHxd+zdSzco+NBllh4UPw9W79xFnI+qZlETEcJ8rCWefJ0MMQfjHMLD4q/Z+tYuEfHgyyx8KD4e7beOQvVXJntVPHMzifi2QP5FYZ4YlhLDOMOhvjFOLdwUcDz5bHwvAeLHcTCRQHPl6/OQs6JXachZ2eudPDkUfhOXp2RtQrzUD638CFhP0cbCz+n9UM7xcKHhP0c7ReHxOe2LXfqzBXVNmsVptz8/8VdPJ29FjG5hYsCni+Phec9WOwgFi4KeL585yzk/ODJ1ExS+E4tMbti9jPbM/Ednl09/+LJLdwo5hmqWHhG9427xsKNYp6hujMLO299B8MTKzzzxKuYM0lhyEn8Sl7tpfKdfVXtkM8tHATx+4yFfp4NHcfCQRC/zzuzcPaUnDGztZwZs7Ud/Gxv7Ie1zKt9iSemU0v8EOcWDoL4fcZCP8+GjmPhIIjf551ZyDed77jKU5UOhnjGs7XEk4c9M088MSrPWhV3ajsYxf8rn1tYiOOxFAs9fCq6jIWFOB5LO/8dKeeHOj0xnRlADDlVnvzEq5g8rN2VV5yqnxv53MIbor2rJBa+y48b3cTCG6K9q2R1FnbeemJ4epXnHJrFs5b8zJOTcQezi3OWh30OcW7hIIjfZyz082zoOBYOgvh9rv4ZKU/M9515FavZQx6FUZyztcSTU+07iycna2f5yTPEuYWDIH6fsdDPs6HjWDgI4ve5cxZ2Ts95oPCdOUEMOVfyqp9OXvXAWmKYVz0TU8S5hYU4Hkux0MOnostYWIjjsbTzz0hnT8wZwFo1M4hRsaplfnbfWbzqjXlysjdimnFuYVOo98Ji4Xu9aXYWC5tCvRd25+dCnoZvOvMqnn33yd+p3YXfxUMdZjlZW8S5hYU4Hkux0MOnostYWIjjsXTn50L1pjPfOT3xnHOdPPlZyzxjxclahenk1V7MPxTnFj4k7OdoY+HntH5op1j4kLCfo139uZCdcmYwz3nDPGNVS4ziYa3CkKcTK07mydPZd6WWew1xbuEgiN9nLPTzbOg4Fg6C+H2uzsLO+04MZ8auvFJd8Ss886xlfjZW51U8xCvMkM8tHATx+4yFfp4NHcfCQRC/z9VZ+MSJOYc4G5jnvsQw34k7nMR09iKePbC2g2FtEecWFuJ4LMVCD5+KLmNhIY7H0urfF+46JecEOTkzOhjWqpg8jLkXY8VDDHmIZ554hWG+GecWNoV6LywWvtebZmexsCnUe2F3ZiFPw7ee+U7cmQ0Ko/LcV/U2W6vwip89MJ7Fs7aIcwsLcTyWYqGHT0WXsbAQx2NpdRbylGpmELNrHuziYW+duHNG8ig8+yeGefIUcW5hIY7HUiz08KnoMhYW4ngs7ZyFu06sZoPKc98OhngVr/Cw9gn+gTO3cBDE7zMW+nk2dBwLB0H8Pt84C6mimivMq5+liCEn8bMY1pKTPMSofKeWmCLOLSzE8ViKhR4+FV3GwkIcj6Wds5AzYOX0T/BwJqneuC/xzLNWYZgnnjExip/4Is4tLMTxWIqFHj4VXcbCQhyPpdVZyDf91InZQ2eurODVGRUn86p2MZ9buCjg+fJYeN6DxQ5i4aKA58vf+P8Lz6ti1UFuoZVdV83GwitVrHKx0Mquq2Zj4ZUqVrlYaGXXVbOx8EoVq1wstLLrqtlYeKWKVS4WWtl11WwsvFLFKhcLrey6ajYWXqlilYuFVnZdNRsLr1SxysVCK7uumo2FV6pY5f4FHaQ4Pt0WyyMAAAAASUVORK5CYII=
</office:binary-data>
</draw:image>
</draw:frame>
</text:p>
That is to say
the encoding cannot be prefixed with data:image/png;base64,
the <draw:image> element cannot have a xlink:href="Pictures/0.png" attributed. Even though the spec says it will be ignored if <office:binary-data> is present. Shrug.
Related
The problem is about getting a direct download link to a Netcloud file.
Documentation :
To obtain a direct link:
POST /ocs/v2.php/apps/dav/api/v1/direct
With the fileId in the body (so fileId=42 for example).
I want to POST this URL with Nodes.js. What is the XML (I guess) format to set "fileId=42" in the body of my request ?
Everything I try returns me
"Invalid query, please check the syntax. API specifications are here:http://www.freedesktop.org/wiki/Specifications/open-collaboration-services." but noway there to get the format.
Samething with curl, no syntax is working.
In a more generic way what is the XML (I guess) format when querying the OCS API?
I answer my question:
At last I suceeded in making it work with curl, single/double quotes in Windows was the problem, fixed using "{" escape character.
This told me this was not about OCS data format itself as data is to be sent as it, ie "fieldId=42"
Switching from NojesJs/https lib to Axios fixed the problem. Probably some content-type header, however I tried 'application/x-www-form-urlencoded' which fits with the data to send.
I am trying to open and edit a .raf file (maybe the Fuji RAW Image File, the result file of a software named SleepSign http://www.sleepsign.com/ ). But I faild to convert it to text file,such as .txt,which I could edit easily and replace the result to what I want. So I can load the replaced-file in SleepSign for manual correction. I test almost all the ways to convert or edit it, but it always break down with a error.I hope for some advises or tools to solve it. Thanks!
You can trie with this one : https://www.onlineconvert.com/by/raf-to-txt-converter.
for infoemration .RAF is a .RAW priority format created by Fuji.
I want to load audio files with names like здраво.mp3, using a NodeJS server. (That's "zdravo" or "hello" in Serbian, if you were wondering).
However, NodeJS makes a request for %D0%B7%D0%B4%D1%80%D0%B0%D0%B2%D0%BE.mp3 instead, which results in the file not being found.
If I drag the file into a browser window from my desktop, the browser is happy to load it as file///path/здраво.mp3, so the issue is not with the way the browser is treating the Unicode string
The HTML page containing the link to the file has this meta tag in the head section...
<meta charset="utf-8" />
... and it is quite happy to display the text "Здраво" on the page, so the Unicode strings are properly formed within the browser.
I am guessing that the browser is converting the name to ISO-8859-1 before sending the request, and that the NodeJS server somehow needs to convert it back to Unicode before looking for it in the file system.
My question is: is there already a module that I can use to do this conversion, and are there examples of how to use it?
SOLUTION: Following the reply from Edwin Dalorzo, here is the one-line fix that I made to my handleRequest() function:
function handleRequest(request, response) {
request.url = decodeURIComponent(request.url) // the fix
var pathname = url.parse(request.url).pathname
It is not clear how you are receiving the encoded string, but for sure you can decode by simply doing:
decodeURIComponent("%D0%B7%D0%B4%D1%80%D0%B0%D0%B2%D0%BE")
And this will give you back your string "здраво"
I am using the XML-INTO op-code to parse a web service request. Every now and then I get errors in the logs
(RNX0351 - "The XML parser detected error code 302").
The help for a 302 is
302 The parser does not support the requested CCSID value or
the first character of the XML document was not '<'
To the best of my knowledge, the first character is "<" and the request is generated from a previous web service call so I would be very suprised if the CCSID has changed.
The error is repeatable, for the specific query so it is almost certainly data related, I am just unsure how I would go about identifying the offending item.
Any thoughts on how to determine the issue, or better yet, how to overcome it?
cheers
CCSID is an AS400/iSeries/Power System attribute, and it applies to the whole IFS.It's like a declaration of what inside the file is, or in other words what its internal encoding "should be".
It's supposed that data content encoding in the file and the file one (the envelope) match, and the box uses this attribute to show and handle corresponding characters.
It sounds like you receive data under one encoding, but CCSID file doesn't match.
Try changing CCSID on your file (only the envelope). E.G.: 37 (american), 500 (latin-1), 819 (utf-8), 850 (dos), 1252 (win) and display file after.You can check first using ls -Sla yourfile in QSH or QP2TERM, or EDTF as well. CHGATTR allows you to change CCSID, as well as setccsid in QSH (again).
This way helped me to find related issues. Remember that although data may be visible in the four hundred, they may not be visible through a share folder in Win. It means that CCSID file, an content encoding don't match.
Hope it helps.
Hi I've seen this error with XML data uploaded to AS400/iSeries/IBM i with FTP and the CCSID 819 (ISO 8859-1 ASCII) and it has some binary garbage in first few positions of file. Changed encoding to CCSID 1208 (UTF-8 with IBM PUA) using FTP "quote type c 1208" and the problem cleared and XML-INTO was successful.
So, suggestion about XML parser error 302 received when using XML-INTO is to look at the file (wrklnk ...) and if first character is not "<" but instead some binary garbage then try CCSID 1208 for utf-8.
Statements in this answer about what 819 is and what ccsid represents utf-8 do not agree with previous answer but are correct, according to IBM documentation:
https://www-01.ibm.com/software/globalization/ccsid/ccsid819.html
https://www-01.ibm.com/software/globalization/ccsid/ccsid1208.html
I'm working on this problem a couple hours,
for me the solution was use option ccsid=UCS2 when you use data structure or variable to store xml.
something like that :
XML-INTO customer %XML( xmlSource : 'ccsid=UCS2');
I have the program running on ccsid = 870, every conversion to ccsid on the xmlSource field don't work,
The strange thing that when I use the file with ccsid = 850, every thing work fine
I mention that becouse this is the first page when you looking about this problem.
Maybe this help someone.
So here is what I've got:
The problem that I face requires me to take a specialized header from WAV1 , and put it as the header for WAV2, in order to make WAV2 work with the API that I'm using. However, whenever I try to replace the first 38 characters of WAV2 with the first 38 of WAV1, I get an error when I try to play the file, I get an error saying that it is not formatted properly. Both WAV1 and WAV2 play properly before the edit.
Do you guys have any idea on what I'm doing wrong?
Thanks so much for your help.
-Rhynorater.
Wav format is a standardised format (see https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ for details about file format). I'm not sure what a "specialized" header is (perhaps you could clarify what your specialised header is?) as the format is standard - any variation would not be a wav file.
The first 38 bytes of a wav file are the header and should adhere to the standard. You cannot copy the header from one file and use it for another as the header contains information specific to the individual file (number of channels, sample rate, file length, etc).
If you both files playback normally (how are you testing this?) I'm not sure why the API you are using is not compatible (which API are you using?).