Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Javascript / Client Side Development

Doubling backslashes in JavaScript - it's unorthodox, but it works...


I've spent the last two hours trying every other solution listed, to
no avail: this works, so I'm sharing it for the other folks who
couldn't find a solution other than switching to another language.

        var fileString = "\\mydev\folder\folder2\folder3\file.txt";

        var myPat = /%5C/g; //this is using regular expression to
define the escaped version of a backslash

        fileString = escape(fileString);
        fileString = fileString.replace(myPat,"%5C%5C");
        fileString = unescape(fileString);

        fileString now equals "\\\\mydev\\folder\\folder2\\folder3\
\file.txt"

Hope this keeps someone else from pounding their heads against the
monitor.  Enjoy!

On May 17, 7:49 pm, i@indigotea.com wrote:

> I've spent the last two hours trying every other solution listed, to
> no avail: this works, so I'm sharing it for the other folks who
> couldn't find a solution other than switching to another language.

>         var fileString = "\\mydev\folder\folder2\folder3\file.txt";

>         var myPat = /%5C/g; //this is using regular expression to
> define the escaped version of a backslash

>         fileString = escape(fileString);
>         fileString = fileString.replace(myPat,"%5C%5C");
>         fileString = unescape(fileString);

>         fileString now equals "\\\\mydev\\folder\\folder2\\folder3\
> \file.txt"

What browser? Did you try this?

fileString.replace(/\\/g,"\\\\");

---
Geoff

i@indigotea.com said the following on 5/17/2007 7:49 PM:

What I get, in IE7 and FF2.0, for that code isn't even close to what you
say it equals.

document.write(fileString) produces:
\\mydev older older2 older3 ile.txt

IE7 window.clipboardData.setData('Text',fileString); gives this:
\\mydev older older2 older3 ile.txt

The boxes in the clipboard appear as some whacked out funny looking
graphic (that I think is neat looking) but won't copy/paste into
Thunderbird for me.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Geoffrey Summerhayes said the following on 5/18/2007 3:40 AM:

var fileString = "c:\new folder";
fileString.replace(/\\/g,"\\\\");
alert(fileString)

Did *you* test it?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

On May 19, 1:54 am, Randy Webb <HikksNotAtH@aol.com> wrote:

The first thing to note is that fileString, as you've presented,
doesn't actually contain a backslash at the time of the attempt to
perform replacement. That's because a backslash in a string literal is
an escape character. In this case, since the backslash precedes an
"n", it results in a newline character being generated when converting
the string to its internal form.

Also, you've used only a string replacement expression, without
assigning the result. Therefore the alert will present the string
without the effect of the replacement operation, i.e, a representation
of the original internal version.

--
   ../rh

ron.h.h@gmail.com said the following on 5/19/2007 3:23 PM:

And testing, if not directly, would have indirectly caused that to be
discovered. If you alert fileString before the replace, the results
should make one wonder why before continuing.

> Also, you've used only a string replacement expression, without
> assigning the result.

True, but, assigning it to another variable had no impact on what was
being written/alerted.

> Therefore the alert will present the string without the effect of
> the replacement operation, i.e, a representation of the original
> internal version.

Even then, it is always better to have the server escape it. By the time
the file path gets to the browser it is too late to try to escape it.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

On May 19, 4:32 pm, Randy Webb <HikksNotAtH@aol.com> wrote:
> ron.h.h@gmail.com said the following on 5/19/2007 3:23 PM:

> > On May 19, 1:54 am, Randy Webb <HikksNotAtH@aol.com> wrote:
> >> Geoffrey Summerhayes said the following on 5/18/2007 3:40 AM:

<..>

Correct! Did *you* test it? ;-)

> > Also, you've used only a string replacement expression, without
> > assigning the result.

> True, but, assigning it to another variable had no impact on what was
> being written/alerted.

Agreed, but that's only because of the choice of the initial test
string that has no backslash to be replaced. It remains a faulty test
which is what I presumed it was to be.

<..>

The point is that

   fileString.replace(/\\/g,"\\\\");

when assigned should give the desired result in a more direct fashion
than the process given by the OP. No?

--
  ../rh

On May 19, 4:54 am, Randy Webb <HikksNotAtH@aol.com> wrote:

> Geoffrey Summerhayes said the following on 5/18/2007 3:40 AM:

> > What browser? Did you try this?

> > fileString.replace(/\\/g,"\\\\");

> var fileString = "c:\new folder";
> fileString.replace(/\\/g,"\\\\");
> alert(fileString)

I wrote half a line of code and you
criticize it based on a half-built
test that is already fatally flawed
no matter what method you use, try:

var fileString = "file:\\\\c:\\new folder\\test\\";
alert(fileString); // print original string for comparison!!!
alert(fileString.replace(/\\/g,"\\\\"); // print result of replace

---
Geoff

Geoffrey Summerhayes said the following on 5/20/2007 4:28 PM:

> On May 19, 4:54 am, Randy Webb <HikksNotAtH@aol.com> wrote:
>> Geoffrey Summerhayes said the following on 5/18/2007 3:40 AM:

>>> What browser? Did you try this?
>>> fileString.replace(/\\/g,"\\\\");
>> var fileString = "c:\new folder";
>> fileString.replace(/\\/g,"\\\\");
>> alert(fileString)

> I wrote half a line of code

That you didn't thoroughly test.

> and you criticize it based on a half-built
> test that is already fatally flawed
> no matter what method you use,

My test was very well thought out and designed to specifically show a
flaw in both approaches. Typically, when a string that contains a file
path needs to be escaped it is because it is not already escaped. If
that string comes from a file input (which some browsers won't let you
read the .value of), then you can not get back to the original if it
contains certain characters in it. My fileString was designed with that
in mind to show that it is not a trivial task.

> try:

> var fileString = "file:\\\\c:\\new folder\\test\\";

Why does that string need escaping though? It is already escaped.

It is easy to come up with a test case to show that a particular piece
of code will work. But, when that piece of code can be shown to be
flawed when presented with another piece of string code then the
original is still flawed.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

On May 20, 4:47 pm, Randy Webb <HikksNotAtH@aol.com> wrote:

> Geoffrey Summerhayes said the following on 5/20/2007 4:28 PM:

> > On May 19, 4:54 am, Randy Webb <HikksNotAtH@aol.com> wrote:
> >> Geoffrey Summerhayes said the following on 5/18/2007 3:40 AM:

> >>> What browser? Did you try this?
> >>> fileString.replace(/\\/g,"\\\\");
> >> var fileString = "c:\new folder";
> >> fileString.replace(/\\/g,"\\\\");
> >> alert(fileString)

> > I wrote half a line of code

> That you didn't thoroughly test.

WTF? I'm sorry, when you were peering
over my shoulder, you should have said
something, I didn't see you here.

> > and you criticize it based on a half-built
> > test that is already fatally flawed
> > no matter what method you use,

> My test was very well thought out and designed to specifically show a
> flaw in both approaches. Typically, when a string that contains a file
> path needs to be escaped it is because it is not already escaped. If
> that string comes from a file input (which some browsers won't let you
> read the .value of), then you can not get back to the original if it
> contains certain characters in it. My fileString was designed with that
> in mind to show that it is not a trivial task.

Pfui. All your test showed was that the GIGO
rule still holds. Putting an alert box showing
the original string before processing would
have a more to the point, and a little more
intellectually honest, because it would have
shown that the input wasn't the *desired* path
string.

> > var fileString = "file:\\\\c:\\new folder\\test\\";

> Why does that string need escaping though? It is already escaped.

Imprecise. It's escaped in the source only.
fileString will hold the unescaped string,
it's length will be 26 NOT 31.

Look, why have the replace in the first
place? Well, when I write a web page to
display HTML, I don't type <body>, I type
&lt;body&gt;. It displays properly, can be
cut and pasted from the page to an editor.
Do people write functions/regexps to do
this kind of translation? Sure.

The only credible reason for having this is
to create a string that can be eval'd or
cut-and-pasted into javascript source, or some
other language that follows the same escaping
rules. A poor man's *PRINT_READABLY* (Common
Lisp), specific to pathnames.

var foo="C:\\somepath";
var bar=eval("'"+foo+"'");
var baz=eval("'"+foo.replace(/\\/g,"\\\\")+"'");
alert('foo = bar: '+(foo==bar)+'\nfoo = baz: '+(foo==baz));

displays

foo = bar: false
foo = baz: true

> It is easy to come up with a test case to show that a particular piece
> of code will work. But, when that piece of code can be shown to be
> flawed when presented with another piece of string code then the
> original is still flawed.

As I said above, if you feed it junk, you
get junk back. That's not flaw in the tool,
it's a mistake on the user's part.

---
Geoff

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc