I am trying to export a text file using JavaScript to be used as macro for Microsoft Dynamics GP.
The problem is Arabic letters don't render correctly when I try to use the macro in GP.
For example "النسر" would render as "ط§ظ„ظ†ط³ط±"
My JavaScript code uses FileSaver.js
var file = new Blob([text], {type:"text/plain;charset=utf-8;"});
saveAs(file, filename);
One solution I found was that after downloading the file I save it with ANSI encoding. But if I changed my charset in the JavaScript Blob object to "ansi" or "Windows-1252" or "cp-1252" it doesn't work.
Note: I am using Chrome on Windows 7
From my experience I have found that Dynamics GP macros uses ANSI.
You will first need to encode your text to ANSI that includes arabic (windows-1256/CP1256).
I used this js library to encode the text:
https://github.com/mathiasbynens/windows-1256
var text= windows1256.encode(text);
Then you will need to convert it to 8 bit unsigned integers and export it using a Blob.
var uint8 = new Uint8Array(text.length);
for (var i = 0; i < uint8.length; i++)
{
uint8[i] = text.charCodeAt(i);
}
var file = new Blob([uint8], {type: 'text/plain;charset=windows-1256'});
I know this answer is too late but I hope it helps.
I know this is super old but I am almost positive, unless something has changed recently, that GP database is all non-unicode. This is not going to work for you.
Related
I ultimately have to consume some data from a Javascript file that looks as follows:
Note: The base64 is illustrative only.
function GetTripsDataCompressed() { return 'QlpoOTFBWSZTWdXoWuEDCAgfgBAHf/.....=='; }
GetTripsDataCompressed() returns a base64 string that is derived as an array of objects converted to JSON using JSON.NET and the resulting string then compressed to bzip2 using SharpCompress with the resulting memory stream Base64 encoded.
This is what I have and cannot change it.
I am struggling to find a bzip2 JavaScript implementation that will take the result of:
var rawBzip2Data = atob(GetTripsDataCompressed());
and convert rawBzip2Data back into the string that is the JSON array. I cannot use something like compressjs as I need to support IE 10 and as it uses typed arrays that means IE10 support is out.
So it appears that my best option is https://github.com/antimatter15/bzip2.js however because I have not created an archive and only bzip2 a string it raises an error of Uncaught No magic number found after doing:
var c = GetTripsDataCompressed();
c = atob(c);
var arr = new Uint8Array(c);
var bitstream = bzip2.array(arr);
bzip2.simple(bitstream);
So can anyone help me here to decompress a BZip2, Base64 encoded string from JavaScript using script that is IE 10 compliant? Ultimately I don't care whether it uses https://github.com/antimatter15/bzip2.js or some other native JavaScript implementation.
It seems to me the answer is in the readme:
decompress(bitstream, size[, len]) does the main decompression of a single block. It'll return -1 if it detects that it's the final block, otherwise it returns a string with the decompressed data. If you want to cap the output to a certain number of bytes, set the len argument.
Also, keep in mind the repository doesn't have a license attached. You'll need to reach out to the author if you want to use the code. That might be tricky given that the repository is eight years old.
On the other hand, the Bzip2 algorithm itself is open-source (BSD-like license), so you can just reimplement it yourself in Javascript. It's just a few hundred lines of relatively straight-forward code.
I'm trying to parse a dicom file in javascript. I download the dicom with axios, the data I get is a string that looks like this:
"\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000DICM\u0002\u0000\u0000\u0000UL\u0004\u0000�\u0000\u0000\u0000\u0002\u0000\u0001\u0000OB\u0000\u0000\u0002\u0000\u0000\u0000\u0000\u0001\u0002\u0000\u0002\u0000UI\u001a\u00001.2.840.10008.5.1.4.1.1.1\u0000\u0002\u0000\u0003\u0000UI0\u00001.3.12.2.1104.5.3.33.1388.11.201703201514180234\u0000\u0002\u0000\u0010\u0000UI\u0014\u00001.2.840.10008.1.2.1\u0000\u0002\u0000\u0012\u0000UI\u0014\u00001.3.12.2.1107.5.3.4\u0000\u0002\u0000\u0013\u0000SH\u000e\u0000Siemens_FLC_60\u0008\u0000\u0005\u0000CS\n\u0000ISO_IR 100\u0008\u0000\u0008\u0000CS\u0016\u0000ORIGINAL\\PRIMARY\\\\RAD \u0008\u0000\u0016\u0000UI\u001a\u00001.2.840.11008.5.1.4.1.1.1\u0000\u0008\u0000\u0018\u0000UI0\u00001.3.12.2.1417.5.3.33.1398.11.201703201514180234\u0000\u0008\u0000 \u0000DA\u0008\u000020170320\u0008\u0000!\u0000DA\u0008\u000020170320\u0008\u0000\"\u0000DA\u0008\u000020170320\u0008\u0000#\u0000DA\u0008\u000020170320\u0008\u00000\u0000TM\u0006\u0000151324\u0008\u00001\u0000TM\u000c\u0000151418.0234 \u0008\u00002\u0000TM\u000c\u0000151418.0234 \u0008\u00003\u0000TM\u000c\u0000151418.0234 \u0008\u0000P\u0000SH\u0000\u0000\u0008\u0000`\u0000CS\u0002\u0000CR\u0008\u0000p\u0000LO\u0008\u0000SIEMENS \u0008\u0000�\u0000LO\u0018\u0000CH Foo Bar - PARIS\u0008\u0000�\u0000PN\u0000\u0000\u0008\u0000\u0010\u0010SH\u0010\u0000AX10094200-1398 \u0008\u00000\u0010LO\n\u0000LDQK001 RC\u0008\u00002\u0010SQ\u0000\u00000\u0000\u0000\u0000��\u0000�(\u0000\u0000\u0000\u0008\u0000\u0000\u0001SH\u0002\u0000RC\u0008\u0000\u0002\u0001SH\u0004\u0000QDOC\u0008\u0000\u0004\u0001LO\n\u0000LDQK001 RC\u0008\u0000>\u0010LO\u001a\u0000RAD_Rachis Cerv. F 3/4 AP \u0008\u0000#\u0010LO\u0002\u000077\u0008\u0000�\u0010LO\u0000\u0000\u0008\u0000�\u0010LO\u0016\u0000Fluorospot Compact FD \u0008\u0000\u0010\u0011SQ\u0000\u0000V\u0000\u0000\u0000��\u0000�N\u0000\u0000\u0000\u0008\u0000P\u0011UI\u0018\u00001.2.840.10008.3.1.2.3.1\u0000\u0008\u0000U\u0011UI&\u00001.3.51.0.1.1.10.2.1.94.2417819.2393805\u0008\u0000\u0011\u0011SQ\u0000\u0000Z\u0000\u0000\u0000��\u0000�R\u0000\u0000\u0000\u0008\u0000P\u0011UI\u0018\u00001.2.840.10008.…"
I need to decode this to a json format (or a readable format like dcmdump does for example) in a js script.
I have tried to use the cornerstone dicom parser (https://github.com/cornerstonejs/dicomParser) like this:
import * as dicomParser from 'dicom-parser';
let enc = new TextEncoder("utf-8")
let arr8 = enc.encode(dicom_data).map(Number)
console.log(dicomParser.parseDicom(arr8))
But I get the following error:
"uncaught exception: dicomParser.parseDicom: missing required meta header attribute 0002,0010".
Does anyone know a simple way to do this?
I am not familiar with JavaScript. However, the attribute (0002,0010 = Transfer Syntax UID) is present in the header.
But the way you handle the data does not appear right to me.
The data is not in DICOM format.
Instead, it seems to be encoded as a string in which non-printable characters have been converted to \u. By this, one byte in the header has been expanded to a two-byte hex number. You should try to obtain the file in its original binary representation
Transcoding to UTF-8 does not appear appropriate to me. Some DICOM attributes contain a value in binary representation. Plus the attributes "addresses" (group, element) and their length are encoded in binary format. Transcoding to UTF-8 will destroy this.
So I think it should work once you pass the original binary DICOM file to the dicomParser without applying any modifications before the parsing.
Well, I never used the toolkit you mentioned in question. I did a simple google search and found github with the documentation.
Documentation also provides a sample to dicom dump. You can view the source of this page in your browser which will provide you complete code to print dump.
Following is snippet:
var reader = new FileReader();
reader.onload = function(file) {
var arrayBuffer = reader.result;
// Here we have the file data as an ArrayBuffer. dicomParser requires as input a
// Uint8Array so we create that here
var byteArray = new Uint8Array(arrayBuffer);
var kb = byteArray.length / 1024;
var mb = kb / 1024;
var byteStr = mb > 1 ? mb.toFixed(3) + " MB" : kb.toFixed(0) + " KB";
I am attempting to write a node app that reads in a set of files, splits them into lines, and puts the lines into an array. Pretty simple. It works on quite a few files except some SQL files that I am working with. For some reason I seem to be getting some kind of unicode output when I split the lines up. The app looks something like this:
fs = require("fs");
var data = fs.readFileSync("test.sql", "utf8");
console.log(data);
lines = data.split("\n");
console.log(lines);
The input file looks something like this:
use whatever
go
The output looks like this:
��use whatever
go
[ '��u\u0000s\u0000e\u0000 \u0000w\u0000h\u0000a\u0000t\u0000e\u0000v\u0000e\u0000r\u0000',
'\u0000g\u0000o\u0000',
'\u0000' ]
As you can see there is some kind of unrecognized character at the beginning of the file. After reading the data in and directly outputting it, it looks okay except for this character. However, if I then attempt to split it up into lines, I get all these unicode-like characters. Basically it's all the actual characters with "\u0000" at the beginning of each one.
I have no idea what's going on here but it appears to have something to do with the characters in the file itself. If I copy and paste the text of the file into another new file and run the app on the new file, it works fine. I assume that whatever is causing this issue is being stripped out during the copy and paste process.
Your file is in UTF-16 Little Big Endian, not UTF-8.
var data = fs.readFileSync("test.sql", "utf16le"); //Not sure if this eats the BOM
Unfortunately node.js only supports UTF-16 Little Endian or UTF-16LE (Can't be sure from reading docs, there is a slight difference between them; namely that UTF-16LE does not use BOMs), so you have to use iconv or convert the file to UTF-8 some other way.
Example:
var Iconv = require('iconv').Iconv,
fs = require("fs");
var buffer = fs.readFileSync("test.sql"),
iconv = new Iconv( "UTF-16", "UTF-8");
var result = iconv.convert(buffer).toString("utf8");
Is this perhaps the BOM (Byte-Order-Mark)? Make sure you save your files without the BOM or include code to strip the BOM.
The BOM is usually invisible in text editors.
I know Notepad++ has a feature where you can easily strip a BOM from a file. Encoding > Encode in UTF-8 without BOM.
I did the following in Windows command prompt to convert the endianness:
type file.txt > file2.txt
Use the lite version of Iconv-lite
var result= "";
var iconv = require('iconv-lite');
var stream = fs.createReadStream(sourcefile)
.on("error",function(err){
//handle error
})
.pipe(iconv.decodeStream('win1251'))
.on("error",function(err){
//handle error
})
.on("data",function(data){
result += data;
})
.on("end",function(){
//use result
});
It seems that there is no xml parsing tool in available JSFL (Adobe Flash-extension Javascript script file) : http://osflash.org/pipermail/flashextensibility_osflash.org/2006-July/000014.html
So, is there an easy and cross-platform way to add a javascript xml parser?
I know this is an old question, but I was looking for a solution to this problem as well (using Flash CS3). I needed to parse XML from a data file on disk. Combining the suggestion of George Profenza I was able to get it to work with using eval(). The key is to remove the first line (the xml declaration):
xmlData = eval( FLfile.read( xmlFile ).split( '\n' ).slice( 1 ).join( '\n' ) );
... and you're good to go!
Well, you can use XML and E4X straight from JSFL using Flash CS3 or newer as the Javascript engine got upgraded to 1.6
Here's a quick snippet that loops through elements in the current selection and traces xml:
var doc = fl.getDocumentDOM();//get the current document ref.
var selection = doc.selection;//get the selection
var layout = <layout />;//create the root node for our xml
var elementsNum = selection.length;//store this for counting*
for(var i = 0 ; i < elementsNum ; i++){
layout.appendChild(<element />);//add an element node
layout.element[i].#name = selection[i].name;//setup attributes
layout.element[i].#x = selection[i].x;
layout.element[i].#y = selection[i].y;
}
fl.trace(layout);
var xml = new XML(FLfile.read(file));
Then you can access all your nodes and attributes by writing this:
xml.nodeName
xml.nodeName.#attribute1
xml.nodeName.#attribute2
nodeName is the name of your node.
attribute1 should be the name of your attribute.
I hope this helps.
If JSFL uses ActionScript at some point, you can just do XML(xml_string) or XMLList(multiple_xml_nodes_string) as long as it's ActionScript 3.0 or higher. ActionScript 3.0 supports E4X witch is native XML in ECMAScript.
What works nicely for me is just creating a SwfWindow. Working in JSFL is nice and fast because you can change out the file without having to restart Flash, but often ActionScript gives you more power.
My current project does a couple tricks:
I will create objects in JSFL and then convert them to XML. I have to serialize them from Object format into a string which I pass to the SwfWindow (Panel). From the Panel, I take the String can convert it into XML. Then you can do anything you want in Actionscript 3.0.
If I just have XML manipulation, I will prompt the User for a XML files path in JSFL code, but hand the URL directly to the Panel, and have the Panel just load the XML directly.
Finally. For saving the XML, I will have to convert the XML to string via, 'xml.toXmlString()', but you also need to remove the '\n' so that you can hand the data to JSFL. I will strip out the '\n' for '|' or whatever you like. Then pass the string to JSFL, and you then can deserialize the string and change the '|' back to '\n' and save the file. Either using the older 'Save Output Panel' method, or using the newer File Write method.
Hope that helps.
function parseXML (xml) {
try { // normal browsers
return (new DOMParser()).parseFromString(xml, "application/xml");
}
catch (e) { // IE
var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async = "false";
xmlDoc.loadXML(xml);
return xmlDoc;
}
}
You might want to read more on DOMParser and the Microsoft.XMLDOM ActiveX object.
I am working on my open source project Downloadify, and up until now it simply handles returning Strings in response to ExternalInterface.call commands.
I am trying to put together a test case using JSZip and Downloadify together, the end result being that a Zip file is created dynamically in the browser, then saved to the disk using FileReference.save. However, this is my problem:
The JSZip library can return either a base64 encoded string of the Zip, or the raw byte string. The problem is, if I return that byte string in response to the ExternalInterface.call command, I get this error:
Error #1085: The element type "string" must be terminated by the matching end-tag "</string>"
ActionScript 3:
var theData:* = ExternalInterface.call('Downloadify.getTextForSave',queue_name);
Where queue_name is just a string used to identify the correct instance in JS.
JavaScript:
var zip = new JSZip();
zip.add("test.txt", "Hello world!\n");
var content = zip.generate(true);
return content;
If I instead return a normal string instead of the byte string, the call works correctly.I would like to avoid using base64 as I would have to include a base64 decoder in my swf which will increase its size.
Finally: I am not looking for a AS3 Zip generator. It is imperative to my project to have that part run in JavaScript
I am admittedly not a AS3 programmer by trade, so if you need any more detail please let me know.
When data is being returned from javascript calls it's being serialized into an XML string. So if the "raw string" returned by JSZip will include characters which make the XML non-valid, which is what I think is happening here, you'll get errors like that.
What you get as a return is actually:
<string>[your JSZip generated string]</string>
Imagine your return string includes a "<" char - this will make the xml invalid, and it's hard to tell what character codes will a raw byte stream translate too.
You can read more about the external API's XML format on LiveDocs
i think the problem is caused by the fact, that flash expects a utf8 String and you throw some binary stuff at it. i think for example 0x00FF will not turn out to be valid utf8 ...
you can try fiddling around with flash.system::System.setCodePage, but i wouldn't be too optimistic ...
i guess a base64 decoder is probably really the easiest ... i'd rather worry about speed than about file size though ... this rudimentary decoder method uses less than half a K:
public function decodeBase64(source:String):ByteArray {
var ret:ByteArray = new ByteArray();
var map:Object = new Object();
var i:int = 0;
for each (var char:String in "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/".split("")) map[char] = i++;
map["="] = 0;
source = source.split("\n").join("").split("\r").join("");//remove linebreaks
for (i = 0; i < source.length/4; i++) {
var buf:int = 0;
for each (char in source.substr(i * 4, 4).split("")) buf = (buf << 6) + map[char];
ret.writeByte(buf >>> 16);
ret.writeShort(buf);
}
return ret;
}
you could simply shorten function names and take a smaller image ... or use ColorTransform or ConvolutionFilter on one image instead of four ... or compile the image into the SWF for smaller overall size ... or reduce function name length ...
so unless you're planning on working with MBs of data, this is the way to go ...