I have a zip file, which contains one CSV file.
I need to Base64 encode this zip file to send to eBay (using their API).
I used this website: http://www.opinionatedgeek.com/DotNet/Tools/Base64Encode/ which works nicely, I upload my zip file and it returns a base64 encoded string which eBay likes.
I need to do what this website does, but using Classic ASP and VB Script.
I already have a base64 encode function, from here: http://www.motobit.com/tips/detpg_base64encode/ so I don't need a script for that. This function takes a parameter, so I need to turn my zip file into a string (I think) to pass into this function.
I have tried using ADODB.Stream and the LoadFromFile method, but the string it returns, after base64 encoding, doesn't match that from the opinionated geek website and isn't accepted by eBay.
This is what I've tried:
Dim objStream, strFileText
Set objStream = Server.CreateObject("ADODB.Stream")
objStream.Type = 1
objStream.Open
objStream.LoadFromFile Server.MapPath("myzipfile.zip")
strFileText = Base64Encode(objStream.Read)
Response.Write strFileText
objStream.Close
Set objStream = Nothing
Can anyone help..?
Thanks!
This is now solved...
I was missing the BinaryToString function between the stream output and the base64 encode.
Now I use:
strFileText = Base64Encode(BinaryToString(objStream.Read))
Where the new function is...
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
S = S & Chr(AscB(MidB(Binary, I, 1)))
Next
BinaryToString = S
End Function
The output from this now matches the output from the opinionated geek tool.
Thanks to ulluoink for pointing me in the right direction!
Related
I am trying to set an image dynamically. Image control is not displaying the image but it is displaying the alternate text. I'm using VS 2008 with vb.net. I used information from this post to construct the code. During debug the file path is correct.
vb Code:
Dim strImgURL As String = "C:\fldr1\fldr2\Projfldr3\images\emps\" 'local dev path where visual studio solution is located
Dim filename As String = System.IO.Path.Combine(strImgURL, Session("EmpID").ToString() & ".jpg")
If (File.Exists(filename)) Then
imgEmp.ImageUrl = filename
Else
filename = System.IO.Path.Combine(strImgURL, "99999.jpg")
imgEmp.ImageUrl = filename
End If
aspx:
<asp:image id="imgEmp" Runat="server" Height="100px" Width="77px"
AlternateText="Employee's picture" />
Is it wrong to use "IO.Path.combine" when passing to ImageUrl?
UPDATE: Still working on this with lessons learned from this thread and this thread using MapPath property to set the path to images. The mappath should theoretically detect file path to the images folder in whatever environment I'm testing.
The only way I can get an image to show is if I hard-code filename value like below (removing any mappath code and system.io.path.combine() code entirely). btw I am taking a Int session variable, Session("EmpID") converting to string to create the filename property (e.g. 12345) - none of the conversion methods I'm using are effective:
1. Session("EmpID").ToString() (or Convert.ToString(Session("EmpID"))
2. strEmpID =Session("EmpID").ToString() + ".jpg"
strImgURL = "http://server/images/" + strEmpID + ".jpg"
Based on the link you provided, System.IO.Path.Combine automatically adds forward slashes to the strings. Then try to remove the excess forward slash at the end of strImgURL:
Dim strImgURL As String = "C:\fldr1\fldr2\Projfldr3\images\emps"
Hope this will help. :)
In C# ASP.Net Website, to transfer the file to client I am using
String file_path = Server.MapPath("~/files/"+file_name);
HttpContext.Current.Response.ContentType = "application/octet-stream";
HttpContext.Current.Response.AddHeader("Content-Disposition", "attachment;filename=" + file_Name);
HttpContext.Current.Response.TransmitFile(file_path);
HttpContext.Current.Response.End();
It is working perfectly, but when the file name contains any spaces the downloaded file has a name only up to the first word. For ex: If my file name is "This is demo.txt" then the downloaded file name becomes "This" with no extension. Hence the user downloading it is not able to identify its type.
How can we avoid happening it for file name containing spaces?
I tried using
String file_path = "'"+Server.MapPath("~/files/"+file_name)+"'";
But it didn't work.
Also its not possible for me to replace ( with '_' or '-') or remove all the spaces present in the file name which are present on the server.
You should enclose the filename in quotes.
HttpContext.Current.Response.AddHeader("Content-Disposition", "attachment;filename=\"" + file_Name + "\"");
And if you are using VS2015 or later, you can make it a bit tidier with string interpolation:
HttpContext.Current.Response.AddHeader("Content-Disposition", $"attachment;filename=\"{file_Name}\"");
Also, the filename in the header does not have to be the same as the name of the file. The filename in the header is only a suggestion to the user.
For full details, see RFC 6266 "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)," especially with regard to which characters may cause problems in a filename.
Using ASP's file system object (FSO), I'm trying to read a txt file with OpenTextFile that contains French characters (e and a with accents for e.g). Those characters come out wrong.
I tried specifying the format to TristateTrue to open the file as Unicode but to no avail.
I've been reading about using the ADO Stream object instead but I hoped there would be a way with FSO. Does anyone have any ideas?
Most likely the file is saved in UTF-8 encoding. The FileSystemObject does not handle UTF-8.
Either have the file saved as Unicode or use the ADODB.Stream object. The ADODB.Stream has a LoadFromFile method and does support UTF-8.
Dim s
Dim stream : Set stream = CreateObject("ADODB.Stream")
stream.CharSet = "UTF-8"
stream.LoadFromFile Server.MapPath("yourfile.txt")
s = stream.ReadAll
stream.Close
I have following piece of code:
public void ProcessRequest (HttpContext context)
{
context.Response.ContentType = "text/rtf; charset=UTF-8";
context.Response.Charset = "UTF-8";
context.Response.ContentEncoding = System.Text.Encoding.UTF8;
context.Response.AddHeader("Content-disposition", "attachment;filename=lista_obecnosci.csv");
context.Response.Write("ąęćżźń󳥌ŻŹĆŃŁÓĘ");
}
When I try to open generated csv file, I get following behavior:
In Notepad2 - everything is fine.
In Word - conversion wizard opens and asks to convert the text. It suggest UTF-8, which is somehow ok.
In Excel - I get real mess. None of those Polish characters can be displayed.
I wanted to write those special encoding-information characters in front of my string, i.e.
context.Response.Write((char)0xef);
context.Response.Write((char)0xbb);
context.Response.Write((char)0xbf);
but that won't do any good. The response stream is treating that as normal data and converts it to something different.
I'd appreciate help on this one.
I ran into the same problem, and this was my solution:
context.Response.BinaryWrite(System.Text.Encoding.UTF8.GetPreamble());
context.Response.Write("ąęćżźń󳥌ŻŹĆŃŁÓĘ");
What you call "encoding-information" is actually a BOM. I suspect each of those "characters" is getting encoded separately. To write the BOM manually, you have to write it as three bytes, not three characters. I'm not familiar with the .NET I/O classes, but there should be a method available to you that takes a byte or byte[] parameter and writes them directly to the file.
By the way, the UTF-8 BOM is optional; in fact, its use is discouraged by the Unicode Consortium. If you don't have a specific reason for using it, save yourself some hassle and leave it out.
EDIT: I just remembered you can also write the actual BOM character, '\uFEFF', and let the encoder handle it:
context.Response.Write('\uFEFF');
I think the problem is with Excel based on Microsoft Excel mangles Diacritics in .csv files. To prove this, copy your sample output string of ąęćżźń󳥌ŻŹĆŃŁÓĘ and paste into a test file using your favorite editor, and save as a UTF-8 encoded .csv file. Open in Excel and see the same issues.
The answer from Alan Moore
translated to VB:
Context.Response.Write(""c)
I have a problem with classc ASP / VBScript trying to read an UTF-8 encoded XML file with MSXML. The file is encoded correctly, I can see that with all other tools.
Constructed XML example:
<?xml version="1.0" encoding="UTF-8"?>
<itshop>
<Product Name="Backup gewünscht" />
</itshop>
If I try to do this in ASP...
Set fso = Server.CreateObject("Scripting.FileSystemObject")
Set ts = fso.OpenTextFile("input.xml", FOR_READING)
XML = ts.ReadAll
ts.Close
Set ts = nothing
Set fso = Nothing
Set myXML = Server.CreateObject("Msxml2.DOMDocument.4.0")
myXML.loadXML(XML)
Set DocElement = myXML.documentElement
Set ProductNodes = DocElement.selectNodes("//Product")
Response.Write ProductNodes(0).getAttribute("Name")
' ...
... and Name contains special characters (german umlauts to be specific) the bytes of the umlaut "two-byte-code" get reencoded, so I end up with two totally crappy nonsense characters. What should be "ü" becomes "ü" - being FOUR bytes in my output, not two (correct UTF-8) or one (ISO-8859-#).
What am I doing wrong? Why is MSXML thinking that the input is ISO-8859-# so that it tries to convert it to UTF-8?
Set ts = fso.OpenTextFile("input.xml", FOR_READING, False, True)
The last parameter is the "Unicode" flag.
OpenTextFile() has the following signature:
object.OpenTextFile(filename[, iomode[, create[, format]]])
where "format" is defined as
Optional. One of three Tristate values used to indicate the format of
the opened file. If omitted, the file
is opened as ASCII.
And Tristate is defined as:
TristateUseDefault -2 Opens the file using the system default.
TristateTrue -1 Opens the file as Unicode.
TristateFalse 0 Opens the file as ASCII.
And -1 happens to be the numerical value of True.
Anyway, better is:
Set myXML = Server.CreateObject("Msxml2.DOMDocument.4.0")
myXML.load("input.xml")
Why should you use a TextStream object to read in a file that MSXML can read perfectly on it's own.
The TextStream object also has no notion of the actual file encoding. The docs say "Unicode", but there is more than one way of encoding Unicode. The load() method of the MSXML object will be able to deal with all of them.