I am building a vCard String in a class and returning it to the form. Below is the string generated.
BEGIN:VCARD\r\nVERSION:3.0\r\nPRODID:-//Apple Inc.//iPhone OS 12.3.1//EN\r\nN:Luna;Giovanni;;;\r\nFN: Giovanni Luna\r\nORG:Packaging Corporation of America;\r\nEMAIL;type=INTERNET;type=pref:gluna#packagingcorp.com\r\nTEL;type=MOBILE;type=VOICE;type=pref:(229) 444-1632\r\nADR;type=WORK;type=pref:;;;Valdosta;GA;31601;United States\r\nEND:VCARD
I pass this to a variable "vCardString" and I add it to the data property of the control at run time. I see the QR code image alter and looks dense, which tells me it wrote the string to the control, when I scan it though, I get a "no usable data is found" error on the camera screen. Not sure what is happening but I am wondering if the string itself needs to be encoded and then a ".toString" added to it.
Related
In a C++/winrt project I have a large number of small svg resources to be loaded from file. Since it would be slow to reload them all from disk at each CreateResources event from the CanvasVirtualControl I have loaded them in advance and stored the data for each in an array. When CreateResources happens my intent is to load a CanvasSvgDocument for each of these by using the CanvasSvgDocument method LoadFromXml(System.string). However, If I create an svgDocument using the resourcecreator, I get an invalid argument crash when calling LoadFromXml(). The resourceCreator argument looks right (VS preview 6 now allows me to see local variables!) and the xml data string argument looks like the valid svg data, so my best guess about the crash is that the data string is the wrong format. The file data is UTF-8. If I convert that to a std::wstring as I must for the LoadFromXml argument can it still be understood as byte data?
For example, I create the std::wstring this way, given a pointer to unsigned char file data and its length in bytes:
m_data_string = std::wstring(data, data + dataLength);
When CreateResources is triggered that datastring is referenced this way:
m_svg = CanvasSvgDocument(resourceCreator);
m_svg.LoadFromXml(resourceCreator, m_data_string);
But LoadFromXml crashes with that invalid parameter error. I see that the length of the data string is correct, but of course that is the number of characters, not the actual size of the data. Could there be a conflict between the UTF-8 attribute in the svg and the fact that it is now recorded as 16-bit characters? If so, how would one load an xml document from such data?
[Update] with the suggestion that I use winrt::to_hstring. I read the unsigned char data into a std::string,
std::string cstring = std::string("");
cstring.assign(data, data + dataLength);
Then I convert that:
m_data_string = winrt::to_hstring(cstring);
And finally try to load an svg as before:
m_svg.LoadFromXml(resourceCreator, m_data_string);
And it crashes as before. I notice that in the debugger that converted string in neither case appeared to be gibberish - in both cases it read in the debugger as the expected svg data. But if this hstring is wide chars wouldn't that be a conflict with the attribute in the svg that identifies it as UTF-8?
[Update] I'm starting to wonder if anyone has ever used CanvasSvgDocument.Draw() to draw an svg loaded from a file. The files are now loading without crashing without any change to their internal encoding reference. But - they won't draw. These files - 239 of them - are UTF-8, svg 1.1, and they display nicely if opened in Edge or any browser. But if I load the file data to an hstring, create a CanvasSvgDocument and then use CanvasSvgDocument.LoadFromXml to load them, they do not draw when called by CanvasSvgDocument's draw method. Other drawing of shapes, etc. works fine during the drawing session. Here is what could be a hint: If I call GetXML() on one of these svgs after it is loaded, what is returned is just this:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"></svg>
That is, the drawing information is not there. Or is this the full extent of what GetXml() is meant to return? That wouldn't seem useful. So perhaps CanvasSvgDocument.LoadFromXml(ResourceCreator, String) doesn't actually work yet?
So I'm back to asking again: is there a way to load a functional CanvasSvgDocument from file data?
My first answer here was wrong: the fault in my code above is that LoadFromXml() is a static method, and someone pointed out to me elsewhere, I was discarding the returned result. It should be theSvg = CanvasSvgDocument::LoadFromXml(string).
Having corrected that, I'm back to the problem of loading UTF-8 data in a method whose argument is a wide-character string. Changing the internal reference to UTF-16 doesn't help after all. Loading the svg with CanvasSvgDocument::LoadAsync(filestream) works, but if I want to load these without re-accessing the disk I will need to find a way to make RandomAccessFileStream from a buffer of bytes and then use LoadAsync. I think. Unless there is some other way to make LoadFromXmL() work - at present it fails with an invalid argument error.
I have implemented this http://jacob.jkrall.net/totp/ in vbscript.
My code given the same hex gives the right 6-digit otp, so that part is working.
I've also verified the HMAC-SHA-1. encoding against an online generator, http://www.freeformatter.com/hmac-generator.html#ad-output, same input gives same output.
My time is the same as http://www.currenttimestamp.com/
I've generated a qrcode at http://www.qr-koder.dk/ with the string otpauth://totp/$LABEL?secret=$SECRET and the google authenticator app reads the code and starts outputting the 6 digit code changing every 30 seconds.
BUT THE CODES FROM THE APP DOES NOT MATCH THE 6-DIGIT CODE THE VBSCRIPT GENERATES!
I've even tried trunc(time/30) +/-7500 steps to see if it was a timezone/daylight saving problem, to no avail.
As the other parts of the routine to generate the 6 digits seem to work I've come to the conclusion I don't understand this:
the url on the qr-code is
otpauth://totp/$LABEL?secret=$SECRET
with the explanation
LABEL can be used to describe the key in your app, while SECRET is the
16-character base32-encoded shared secret, which is now known to both
the client and the server.
So when I calculate HMAC-SHA-1(SECRET, time()/30)
should the SECRET be the same string given to both the app and the calculation?
If I select a secret of 1234567890, the base32 is GEZDGNBVGY3TQOJQ according to http://emn178.github.io/online-tools/base32_encode.html.
Should I then take
HMAC-SHA-1("1234567890", time()/30)
or
HMAC-SHA-1("GEZDGNBVGY3TQOJQ", time()/30)
?
I believe I've tried both, and neither works.
The system unix time is correct.
I guess the problem might be with the secret in your HMAC-SHA-1 function. It very much depends on what the HMAC-SHA-1 expects.
Your string "123456790" might be a binary string. Is it an ascii representation or utf8? I.e. is this string 10 bytes or 20 bytes long?
I recommend getting the input string in your VBScript right.
On the other hand, instead of writing your own VBScript, you can also use a ready made solution like the privacyIDEA authentication server, which is open source and also comes with TOTP.
I ran into a situation where I needed to find the memory address of a String that I use in a piece of VB Code. I tried using various debuggers and also using the simple procexplorer to display a list of printable strings in memory. But it does not show anything which puzzles me. Does VB (.net framework 4) use some kind of encoding mechanism to store strings so that it does not appear in a printable format ?
Here's the variable am trying to locate in memory: "spoilt"
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
MessageBox.Show("Button1")
Dim spoilt As String
spoilt = TextBox1.Text
Label1.Text = spoilt
End Sub
These are managed strings. I'm not sure if the tools you are using know how to read managed strings out of memory.
.NET string literals are stored in the metadata section of the portable executable. Unless the tool understand how to read it out of .NET's metadata section, it won't find it. You can see the strings with a tool like ildasm. Under "View", and "MetaInfo", click "Show!". Somewhere in the new window will be a "User Strings" section. Here's mine for a sample application.
User Strings
-------------------------------------------------------
70000001 : (35) L"Property can only be set to Nothing"
70000049 : (28) L"WinForms_RecursiveFormCreate"
70000083 : (26) L"WinForms_SeeInnerException"
700000b9 : ( 7) L"Button1"
700000c9 : ( 6) L"Label1"
700000d7 : ( 8) L"TextBox1"
700000e9 : ( 5) L"Form1"
700000f5 : (29) L"WindowsApplication1.Resources"
Here we can see that the MetaData Token of the string (in my case) is 700000b9.
Now if you wanted to find the address of the string at runtime...
The tool of choice I would use to do this is WinDbg with the SOS extensions. Here's how to find that string in memory.
This is all for the x86 .NET Framework 4.
Start by opening WinDbg and selecting Open Process and open your EXE. It will immediately break to give you the opportunity to set things up, like breakpoints.
Set a stop on exception when the CLR JIT is loaded. This will be the right time to load SOS debugger extension.
sxe ld:clrjit
Then go ahead and continue execution with g.
At this point we should have hit a breakpoint on a modload for clrjit.
ModLoad: 57910000 57970000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll
From there we can load the SOS debugging extensions with .loadby sos clr.
We can test that SOS loaded correctly by running !eeversion to get the Execution Enging version. For me this gives "4.0.30319.269 retail".
Now to find that string. Let's start by breaking when the System.Windows.Forms.dll module is loaded.
sxe ld:System.Windows.Forms
And use g to continue the execution. We should break when the module is loaded. Go ahead and step over it so the module is actually loaded with p.
Now we can put a breaking on MessageBox.Show like so:
!bpmd System.Windows.Forms.dll System.Windows.Forms.MessageBox.Show
Now go ahead and go with g. Your application should be running now. Go ahead and click the button, and our breakpoint should be hit.
Then we can step into Show with t.
From there we can use !clrstack -p to show the stack trace with parameters. At the top of the stack will be the call to MessageBox.Show.
004ee820 5c22839c System.Windows.Forms.MessageBox.Show(System.String)
PARAMETERS:
text (<CLR reg>) = 0x022a1058
So now we know that the string's address is 0x022a1058. This of course will be different for you. If we do a !do 0x022a1058 it gives us the string:
Name: System.String
MethodTable: 638afb08
EEClass: 635e8bb0
Size: 28(0x1c) bytes
File: C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String: Button1
To answer my own question regarding encoding: Yes, Unicode encoding is used to store all strings. The above answer by #vcsjones provides a detailed explanation of how to find the memory location of these strings.
For the benefit of people who are looking for answers on how to find this address, there is a simpler way. mona.py (http://redmine.corelan.be/projects/mona) is a plugin for immunity debugger to do this job. I used it to find the memory location. The only reason I wasn't able to find what I was looking for is because of the unicode format. But, with mona.py there is an option to search for unicode strings as well.
I need to generate an URL string for a SSRS report (in order to link it with our CRM software). The report name is in Hebrew. When I send the URL string (with Heb) to Internet Explorer, it doesn't recognize the address because it isn't encoded with Percent-encoding (BTW, it works fine in Firefox). (Sending a URL with English only does work fine that way.)
Anyway, I tried to perform the encoding. I succeeded converting it to URI with UNICODE characters. I need to get the URI in UTF-8. For example, the letter 'י' should be converted into '%d7%99' and not to '%05%D9'.
I included a link:
A table with the codes, for your use, if needed.
I need the conversion\encoding function for 1 character. I can build the rest of the script / function for the complete string by myself.
I used a script which used the master.sys.fn_varbintohexstr function. As I said, though, the results aren't proper for IE.
the following:
SELECT master.sys.fn_varbintohexstr((CAST (N'י' AS varbinary)))
will get 0xd905, which I formatted into percent encoding. I should get 'd7 99' instead.
wrap up:
I convert an Hebrew character into URI percent encoding. I get a unicode result. I wish > to get a utf8 result.
Input = 'י'. Current output = %d9. Wanted output = %d7%99
How can I get those results?
I have had to deal with a few similar problems and there are two approaches that you may wish to consider; the first is to transform your data into HTML in the query and then render the result as HTML in the RDL, the second is to use JQuery to identify those cells with the incorrect value on the client and then transform that cell (again, using JQuery). The benefit of the second option is that if the server rendering is working on Firefox the transformation overhead doesn't get invoked. The downside is that if you are not rendering the report as HTML it won't work.
For the first option, in the select statement you would need to alter the appropriate column to produce a nvarchar value that looks like
<span style="font=yourfont;" charset="UTF-8">linkname</span>
With that string as data you then assign that to the appropriate columns (or cells, as needed)
In the RDL designer drag a placeholder for your field onto the designer and right click the placeholder and select placeholder properties then you can select to display the content as HTML.
According to MSDN vb.net uses this extended character set. In my experience it actually uses this:
What am I missing? Why does it say it uses the one and uses the other?
Am I doing something wrong?
Is there some sort of conversion tool to the original character set?
This behaviour is defined in the documentation of the Chr command:
The returned value depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class in the System.Globalization namespace. You can obtain ANSICodePage by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
So, the output of Chr for values greater than 127 is system-dependent. If you want reproducible results, create the desired instance of Encoding by calling Encoding.GetEncoding(String), then use Encoding.GetChars(Byte()) to convert your numeric values into characters.
If you go up one level in the chart linked in your question, you will see that they do not claim that this chart is always the output of the Chr command:
The characters that appear in Windows above 127 depend on the selected typeface.
The charts in this section show the default character set for a console application.
Your application is a WinForm application, not a console application. Even in the console, the character set used can be changed (for example, by using the chcp command), hence the word "default".
For detailed information about the encodings used in .net, I recommend the following MSDN article: Character Encoding in the .NET Framework.
The first character set is Code Page 437 (CP437), the second looks like Code Page 1252 (CP1252) also known as Windows Latin-1.
I'd guess VB.Net is simply picking up the default encoding for the PC.
How did you write all this? Because usually, when you use a output stream function, you can specify the encoding going with it.
Edit: I know this is not C#, but you can see the idea...
You'd have to set the encoding of your filestream, by doing something like this:
Setting the encoding when creating the filestream