gpt4 book ai didi

C# Tracing 截断长消息

转载 作者:太空狗 更新时间:2023-10-29 23:29:19 24 4
gpt4 key购买 nike

在 C# 中,我启用了跟踪和网络跟踪源。

    <?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<system.diagnostics>
<sources>
<source name="System.Net" tracemode="includehex" maxdatasize="1024">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
</sources>
<switches>
<add name="System.Net" value="Verbose"/>
</switches>
<sharedListeners>
<add name="System.Net"
type="TraceTest.StringWriterTraceListener, TraceTest"
initializeData="myfile.log"
/>
</sharedListeners>
<trace autoflush="true" indentsize="4" />
</system.diagnostics>
</configuration>

但是较长的消息会被截断(像 12Kb/30 行一样长,不像 1GB 那样长!)所以我最终遇到的情况是只记录了部分网络请求 header 。

如何解决?

或者您知道一本非常详细地解释 .Net 跟踪和调试的书籍或资源吗?

日志示例:

            System.Net Information: 0 : [1204] Connection#63291458 - Received headers
{
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=10
Content-Type: text/html; charset=windows-1251
Date: Mon, 04 Jul 2016 17:50:33 GMT
Set-Cookie: uid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0,uid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/,uid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.zamunda.net,pass=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0,pass=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/,pass=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.zamunda.net,bitbucketz=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0,bitbucketz=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/,bitbucketz=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.zamunda.net,cats=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0,cats=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/,cats=deleted;
expires=...}.

这是一条消息,TraceListener 上的 Write 方法以某种方式被调用,该单个消息作为被截断的参数(“...}”在结束)

另外,cookies 写得很糟糕,几乎无法解析,但我可以接受...

是的,可悲的是,除了篡改 System.dll 或使用一些奇怪而复杂的类型继承之外,没有什么可做的。

最佳答案

您不会获得额外的数据。

您的典型示例来自名为 ParseResponseData 的私有(private)方法,该方法调用此方法:

Logging.PrintInfo(Logging.Web, this, SR.GetString("net_log_received_headers", new object[]
{
this.m_ResponseData.m_ResponseHeaders.ToString(true)
}));

带有GetString 方法的内部密封静态类SR 是这里的罪魁祸首。 net_log_received_headers 资源字符串是 Received headers {{{0}}}。。 ILSpy 揭示了这段代码:

public static string GetString(string name, params object[] args)
{
SR sR = SR.GetLoader();
if (sR == null)
{
return null;
}
string @string = sR.resources.GetString(name, SR.Culture);
if (args != null && args.Length != 0)
{
for (int i = 0; i < args.Length; i++)
{
string text = args[i] as string;
if (text != null && text.Length > 1024)
{
args[i] = text.Substring(0, 1021) + "...";
}
}
return string.Format(CultureInfo.CurrentCulture, @string, args);
}
return @string;
}

你注意到这 block :

if (text != null && text.Length > 1024)
{
args[i] = text.Substring(0, 1021) + "...";
}

无论你向它扔什么,它都会重写参数以将其长度限制为 1024 个字符。

由于 ResponseHeaders 集合将其所有名称/值写入单个字符串,一旦将其交给 SR.GetString,所有的努力和内存都被浪费了。

SR.GetString 参与日志记录时,您将面临数据被截断的风险。了解发生这种情况的唯一方法是检查程序集或 .Net Reference Source

当调用内部 Logging 类的 Dump 方法时,使用配置中的 maxdatasize 设置。但是,您不必猜测数据是否被截断,因为它会在日志文件中告诉您:

int maxDumpSizeSetting = Logging.GetMaxDumpSizeSetting(traceSource);
if (length > maxDumpSizeSetting)
{
Logging.PrintLine(traceSource, TraceEventType.Verbose, 0, string.Concat(new string[]
{
"(printing ",
maxDumpSizeSetting.ToString(NumberFormatInfo.InvariantInfo),
" out of ",
length.ToString(NumberFormatInfo.InvariantInfo),
")"
}));
length = maxDumpSizeSetting;
}

关于C# Tracing 截断长消息,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38189689/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com