Как правило, вам нужно заменить "\n"
на space
и поместить ваши имена файлов в кавычки ''
. Следующий код может быть одним из способов сделать это. Кстати, ваш код будет генерировать выходные имена, такие как «Data1.dat.png», а не «Data1.png» из «Data1.csv». Также следует помнить о разнице одинарных и двойных кавычек.
### File list with space in filenames (Windows)
reset session
InputPath = 'D:\data\my data\'
OutputPath = 'D:\data\'
SearchExp = 'dir /b "' . InputPath . '*.dat"'
# print SearchExp
LIST = system(SearchExp)
# print LIST
LIST = LIST eq "" ? LIST : "'".LIST."'" # add ' at begining and end
FILES = ""
do for [i=1:strlen(LIST)] {
FILES = (LIST[i:i] eq "\n") ? FILES."' '" : FILES.LIST[i:i]
}
# print FILES
print sprintf("The list contains %d files", words(FILES))
do for [FILE in FILES] {
InputFile = InputPath.FILE
OutputFile = OutputPath.FILE[1:strlen(FILE)-4].".png"
print InputFile
print OutputFile
# or plot your files
}
### end of code
Я нашёл правильный способ вернуть XML клиенту в ASP.NET. Думаю, если я укажу неправильные пути, это сделает правильный путь более понятным.
Неправильно:
Response.Write(doc.ToString());
Неправильно:
Response.Write(doc.InnerXml);
Неправильно:
Response.ContentType = "text/xml";
Response.ContentEncoding = System.Text.Encoding.UTF8;
doc.Save(Response.OutputStream);
Исправлено:
Response.ContentType = "text/xml"; //Must be 'text/xml'
Response.ContentEncoding = System.Text.Encoding.UTF8; //We'd like UTF-8
doc.Save(Response.Output); //Save to the text-writer
//using the encoding of the text-writer
//(which comes from response.contentEncoding)
Делать не использовать Ответ. OutputStream
Do use Response.Output
Both are flows, but Output
is a TextWriter. Когда XmlDocument
сохраняется в TextWriter, он будет использовать кодировку TextWriter, указанную этим TextWriter. XmlDocument автоматически изменит узел xml декларации на кодировку, используемую TextWriter. Например, в этом случае узел XML декларации:
<?xml version="1.0" encoding="ISO-8859-1"?>
станет
<?xml version="1.0" encoding="UTF-8"?>
Это потому, что TextWriter был установлен в UTF-8. (Подробнее об этом позже). Так как TextWriter подает символьные данные, он будет кодировать их байтовыми последовательностями, соответствующими его заданной кодировке.
Неправильно:
doc.Save(Response.OutputStream);
В данном примере документ некорректно сохраняется в OutputStream, который не изменяет кодировку и может не совпадать ни с кодировкой контента ответа, ни с кодировкой, заданной узлом XML-объявления.
Исправьте
doc.Save(Response.Output);
XML-документ корректно сохраняется в объект TextWriter, что обеспечивает правильную обработку кодировки.
Кодировка, переданная клиенту в заголовке:
Response.ContentEncoding = ...
должна совпадать с кодировкой XML документа:
<?xml version="1.0" encoding="..."?>
должна совпадать с фактической кодировкой, присутствующей в последовательностях байтов, передаваемых клиенту. Чтобы заставить все три эти вещи согласиться, установите единственную строку:
Response.ContentEncoding = System.Text.Encoding.UTF8;
Когда кодировка установлена на объекте Response, она устанавливает ту же самую кодировку на TextWriter. Набор кодировок TextWriter заставляет XmlDocument изменить xml декларацию:
<?xml version="1.0" encoding="UTF-8"?>
при сохранении документа:
doc.Save(someTextWriter);
Вы не хотите сохранять документ в двоичном потоке или записывать строку:
Неверно:
doc.Save(Response.OutputStream);
Здесь XML некорректно сохраняется в двоичном потоке. Окончательная последовательность кодирования байтов не будет соответствовать ни XML-декларации, ни контент-кодировке ответа веб-сервера.
Неправильно:
Response.Write(doc.ToString());
Response.Write(doc.InnerXml);
Здесь XML некорректно преобразуется в строку, которая не имеет кодировки. Узел XML декларации не обновляется, чтобы отразить кодировку ответа, и ответ не правильно закодирован, чтобы соответствовать кодировке ответа. Кроме того, при хранении XML в промежуточной строке теряется память.
Вы не хотите сохранять XML в строку, или запихивать XML в строку и response.Write
a string, потому что:
- doesn't follow the encoding specified
- doesn't set the XML declaration node to match
- wastes memory
Do use doc.Save(Response.Output);
Do not use doc. Save(Response.OutputStream);
Do not use Response.Write(doc.ToString());
Do not use 'Response.Write(doc.InnerXml);`
The ContentType's Response's must be set to "text/xml"
. В противном случае клиент не будет знать, что вы отправляете ему XML.
Response.Clear(); //Optional: if we've sent anything before
Response.ContentType = "text/xml"; //Must be 'text/xml'
Response.ContentEncoding = System.Text.Encoding.UTF8; //We'd like UTF-8
doc.Save(Response.Output); //Save to the text-writer
//using the encoding of the text-writer
//(which comes from response.contentEncoding)
Response.End(); //Optional: will end processing
Rob Kennedy имел хорошее замечание, что я не включил пример "от начала до конца".
GetPatronInformation.ashx:
<%@ WebHandler Language="C#" Class="Handler" %>
using System;
using System.Web;
using System.Xml;
using System.IO;
using System.Data.Common;
//Why a "Handler" and not a full ASP.NET form?
//Because many people online critisized my original solution
//that involved the aspx (and cutting out all the HTML in the front file),
//noting the overhead of a full viewstate build-up/tear-down and processing,
//when it's not a web-form at all. (It's a pure processing.)
public class Handler : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
//GetXmlToShow will look for parameters from the context
XmlDocument doc = GetXmlToShow(context);
//Don't forget to set a valid xml type.
//If you leave the default "text/html", the browser will refuse to display it correctly
context.Response.ContentType = "text/xml";
//We'd like UTF-8.
context.Response.ContentEncoding = System.Text.Encoding.UTF8;
//context.Response.ContentEncoding = System.Text.Encoding.UnicodeEncoding; //But no reason you couldn't use UTF-16:
//context.Response.ContentEncoding = System.Text.Encoding.UTF32; //Or UTF-32
//context.Response.ContentEncoding = new System.Text.Encoding(500); //Or EBCDIC (500 is the code page for IBM EBCDIC International)
//context.Response.ContentEncoding = System.Text.Encoding.ASCII; //Or ASCII
//context.Response.ContentEncoding = new System.Text.Encoding(28591); //Or ISO8859-1
//context.Response.ContentEncoding = new System.Text.Encoding(1252); //Or Windows-1252 (a version of ISO8859-1, but with 18 useful characters where they were empty spaces)
//Tell the client don't cache it (it's too volatile)
//Commenting out NoCache allows the browser to cache the results (so they can view the XML source)
//But leaves the possiblity that the browser might not request a fresh copy
//context.Response.Cache.SetCacheability(HttpCacheability.NoCache);
//And now we tell the browser that it expires immediately, and the cached copy you have should be refreshed
context.Response.Expires = -1;
context.Response.Cache.SetAllowResponseInBrowserHistory(true); //"works around an Internet Explorer bug"
doc.Save(context.Response.Output); //doc saves itself to the textwriter, using the encoding of the text-writer (which comes from response.contentEncoding)
#region Notes
/*
* 1. Use Response.Output, and NOT Response.OutputStream.
* Both are streams, but Output is a TextWriter.
* When an XmlDocument saves itself to a TextWriter, it will use the encoding
* specified by the TextWriter. The XmlDocument will automatically change any
* XML declaration node, i.e.:
* <?xml version="1.0" encoding="ISO-8859-1"?>
* to match the encoding used by the Response.Output's encoding setting
* 2. The Response.Output TextWriter's encoding settings comes from the
* Response.ContentEncoding value.
* 3. Use doc.Save, not Response.Write(doc.ToString()) or Response.Write(doc.InnerXml)
* 3. You DON'T want to save the XML to a string, or stuff the XML into a string
* and response.Write that, because that
* - doesn't follow the encoding specified
* - wastes memory
*
* To sum up: by Saving to a TextWriter: the XML Declaration node, the XML contents,
* and the HTML Response content-encoding will all match.
*/
#endregion Notes
}
private XmlDocument GetXmlToShow(HttpContext context)
{
//Use context.Request to get the account number they want to return
//GET /GetPatronInformation.ashx?accountNumber=619
//Or since this is sample code, pull XML out of your rear:
XmlDocument doc = new XmlDocument();
doc.LoadXml("<Patron><Name>Rob Kennedy</Name></Patron>");
return doc;
}
public bool IsReusable { get { return false; } }
}
Идеально Вы использовали бы ashx для отправки XML, хотя я действительно позволяю коду в ASPX прерывать нормальное выполнение.
Response.Clear()
я не использую это, если Вы не уверенный Вы уже вывели что-нибудь в ответе, движение находит его и избавляется от него.
Response.ContentType = "text/xml"
Определенно, общий клиент не примет содержание как XML без этого существующего типа контента.
Response.Charset = "UTF-8";
Позволяют классу ответа обработать создание заголовка типа контента правильно. Используйте UTF-8, если Вы не имеете действительно, действительно серьезное основание не к.
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetAllowResponseInBrowserHistory(true);
, Если Вы не отправляете заголовки кэша, некоторые браузеры (а именно, IE) будут кэшировать ответ, последующие запросы не обязательно прибудут в сервер. Вам также нужно к AllowResponseInBrowser, если Вы хотите, чтобы это работало по HTTPS (из-за еще одной ошибки в IE).
Для отправки содержания XmlDocument просто используйте:
<забастовка> забастовка>
dom.Save(Response.OutputStream);
dom.Save(Response.Output);
Просто быть уверенным соответствие кодировки, (другое серьезное основание использовать UTF-8).
Эти XmlDocument
объект автоматически скорректирует свое встроенное encoding="..."
кодирование к тому из Response
(например, UTF-8
)
Response.End()
, Если Вы действительно имеете к в ASPX, но это немного решительно, в ASHX не делают этого.
Ниже пример корректного способа, которым я думаю. По крайней мере, это - то, что я использую. Необходимо сделать Ответ. Ясный избавиться от любых заголовков, которые уже заполняются. Необходимо передать корректный ContentType text/xml. Это - способ, которым Вы служите xml. В целом Вы хотите служить ему в качестве набора символов UTF-8 как, именно это ожидает большинство синтаксических анализаторов. Но я не думаю, что это должно быть это. Но если Вы изменяетесь, это удостоверяется, что изменило Ваше xml объявление документа и указало на набор символов там. Необходимо использовать XmlWriter, таким образом, можно на самом деле записать в UTF-8 и не независимо от того, что набор символов является значением по умолчанию. И иметь его правильно кодируют Ваши данные XML в UTF-8.
' -----------------------------------------------------------------------------
' OutputDataSetAsXML
'
' Description: outputs the given dataset as xml to the response object
'
' Arguments:
' dsSource - source data set
'
' Dependencies:
'
' History
' 2006-05-02 - WSR : created
'
Private Sub OutputDataSetAsXML(ByRef dsSource As System.Data.DataSet)
Dim xmlDoc As System.Xml.XmlDataDocument
Dim xmlDec As System.Xml.XmlDeclaration
Dim xmlWriter As System.Xml.XmlWriter
' setup response
Me.Response.Clear()
Me.Response.ContentType = "text/xml"
Me.Response.Charset = "utf-8"
xmlWriter = New System.Xml.XmlTextWriter(Me.Response.OutputStream, System.Text.Encoding.UTF8)
' create xml data document with xml declaration
xmlDoc = New System.Xml.XmlDataDocument(dsSource)
xmlDoc.DataSet.EnforceConstraints = False
xmlDec = xmlDoc.CreateXmlDeclaration("1.0", "UTF-8", Nothing)
xmlDoc.PrependChild(xmlDec)
' write xml document to response
xmlDoc.WriteTo(xmlWriter)
xmlWriter.Flush()
xmlWriter.Close()
Response.End()
End Sub
' -----------------------------------------------------------------------------
Походит по крайней мере на 10 вопросов одновременно здесь, пара точек.
Ответ. Ясный - это действительно зависит от того, что еще продолжается в приложении - если у Вас есть httpmodules рано в конвейере, который мог бы писать материал, который Вы не хотите - затем очищают его. Протестируйте его и узнайте. Fiddler или Wireshark, полезный для этого.
Тип контента к text/xml - да - хорошей идее - чтение на спецификации HTTP относительно того, почему это важно. IMO любой делающий веб-работу должен был считать 1,0 и 1,1 спецификации, по крайней мере, однажды.
Кодирование - как Ваш xml кодируется - если это - utf-8, затем скажите так, в противном случае скажите что-то еще соответствующее, просто удостоверьтесь, что они все соответствуют.
Page - лично, использовал бы ashx или httpmodule, если Вы используете страницу, и хотите ее немного быстрее, избавляетесь от autoeventwireup и связываете обработчики событий вручную.
, вероятно, была бы определенная трата памяти для дампа xml в строку сначала, но это во многом зависит от размера xml относительно того, замечали ли Вы когда-либо.
, Поскольку другие предложили, сохранив xml к потоку вывода, вероятно, самое быстрое, я обычно делал бы это, но если Вы не уверены, тестируете его, не полагайтесь на то, что Вы читаете в межсети. Не просто верьте чему-либо, что я говорю.
Для другого подхода, если xml не изменяется так очень, Вы могли бы просто записать это в диск и служить файлу непосредственно, который, вероятно, будет довольно производителен, но как все в программировании, он зависит...
Вы уже в основном ответили на что-нибудь и все, таким образом, я не уверен, что точка здесь?
FWIW я использовал бы httphandler - там не кажется никаким смыслом в вызове жизненного цикла страницы и необходимости иметь дело с вырезанием битов состояния отображения и сессии и что имеет Вас, которые не имеют смысла для документа XML. Это похоже на покупку автомобиля и разделение его для частей для создания мотоцикла.
И тип контента все важно, это - как запрашивающая сторона знает, что сделать с ответом.