Quite simply, I am only able to write to this card in hexadecimal. After much research, I can only find methods to write a working URL(that opens the browser on mobile), that use specific apps that are not compatible with the card I have. I would love it if one of you clever folks could explain to me the method by which I can turn a URL into the correct format, and where(sector, headers etc...) I should store it within my card. Thanks
Unfortunately Mifare Classic Tags are non standard, so there is no reliable way on all mobile hardware to write a URL that will automatically open a browser.
Most mobile hardware supports the NFC standard Tag's and some support reading from Mifare Classic Tags (but not all).
If reading from a non standard Mifare Classic Tag is supported then there is a chance that the NDEF data format will be also supported.
All mobiles will handle automatically URL's encoded in the NDEF format.
First you need to format the Mifare Classic Tag in a way to store NDEF, see the NXP application note https://www.nxp.com/docs/en/application-note/AN1305.pdf on how to do this.
Once configured to store NDEF data you can store a URL using NDEF URI type - details at https://github.com/haldean/ndef/blob/master/docs/NFCForum-TS-RTD_URI_1.0.pdf
Writing the data in this way will cause a fair number of mobiles to open a URL in a browser without any App, but also a fair number won't even read the Mifare Tag.
Related
I'm trying to record some text values (cmi.interactions.n.learner_response, and cmi.interactions.n.description) on the backend. I'm sending them in a post response from a JS object that uses JSON.stringify.
Inspecting the response in PHP, accented characters äöå (and spaces) are recorded as underscores in learner_response, and in description, they are omitted altogether. Inspecting the response string, it appears to be an ASCII encoded string.
Is it possible to set encoding in SCORM 2004 so that I can see accented characters in the response? My client would like record the interactions more thoroughly. The content was created in Adobe Captivate.
Thanks.
Essentially, no. SCORM's scope limits it to what is happening in the runtime layer that is implemented as the JavaScript API that the SCORM player (the thing launching the content) provides. So the transfer mechanism between that runtime environment and the storage layer (whether that is on a server, local, etc.) is outside the scope of the spec and is therefore implementation specific.
There is reference to ISO-10646-1 which will take you down a path that likely leads to not a lot more information. Essentially it is a character set without including specifics about how to handle those elements, which for this use case probably boils down to JavaScript string.
Having said all of that you should seek support from the SCORM player to see if they have the ability to adjust that so that larger ranges of characters can be supported.
data:text/html;base64,77u/data:text/html;base64,77u/PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuLVVTIiBjbGFzcz0ia
I saw a url as the one above.
what is it called ?
how do i encrypt a url to be like that ?
It's called base64 encoding; what's encoded in your example is not a web address, but actual HTML content itself.
Note that it's trivially easy to decode for anyone. Base64 is not suitable for "encrypting" resources. You can not hide content or URLs from your visitors this way.
Using this makes sense only in a very limited set of situations, like when you want to reduce the number of HTTP requests and store multiple resources inside one HTML page.
If you still want to use it - there are online base64 encoders and decoders like this one. You'd use what you have above and replace everything after base64,.
I have seen the xbuf from gwan. Not sure when it is not a good use for it. Can it be used for integers or float? When is it not recommended to be used? I am very much inclined to use it as often as possible.
As an application server, G-WAN is expected to generate dynamic contents.
In this case, the server is building a reply served to clients.
Part of these dynamic contents are binary (like pictures) and this is why G-WAN offers a native ultra-fast in-memory GIF, charts, and frame-buffer API. More complex images can be generated with general-purpose libraries like Cairo (used by Internet browsers).
But most dynamic contents are text (like HTML pages, JSON payloads, etc.).
And this is the purpose of the G-WAN xbuffer API which works as an extended snprintf() - supporting strings, integers, floats, base64, hexdump, binary formating (3 => "11") and more.
The loan.c example illustrates very well how relevant, fast and versatile xbuffers are.
when should you not use it?
When sending an empyt reply (HTTP status code 204), or (less likely but still possible) when appending data directly in a previously resized reply buffer. G-WAN examples show how to do that, look at the fractal.c file.
I´m working on an application based on directshow that has to convert an AVI source file to to an mp4-file that can be played back with Quicktime.
Since 3ivx, according to my web research the most popular way to fulfill this task, has become commercial (and my budget is quite limited), I decided to use a solution based on ffdshow.
I created a simple graph in graphedit, using LAME for audio encoding and GDCL MPEG 4 Multiplexor for the muxing, but everytime I try to play the movie with Quicktime, I´m getting an error indicating a wrong "sample description".
Playback with Windows Media Player is working, except that there is no sound.
My guess is that there´s a problem with the muxer, because every time I try to add audio encoding, graphedit automatically adds an decoder after the encoding unit (see picture link).
http://imageshack.us/photo/my-images/39/graphjrgr.png/
Any ideas on how to integrate ffdshow in a better way, tips for alternative mp4 muxers, or a complete different approach are appreciated!
The GDCL muxer has limited number of audio formats that it supports, probably you should check the source code for the muxer to see if the formats you are using are in fact supported. Basically, you need to choose an audio encoder that the mux recognizes as valid. It might be possible to use GraphEdit to choose different properties for the encoder filter that allow things to work better.
I have had some luck with the Monogram x264(video) and AAC(audio) encoders. See http://blog.monogram.sk/janos/directshow-filters/
Finally, try the debug version of the GDCL mp4 muxer.
Also, you must be aware of MPEG-4 LA licensing requirements for x264 http://www.mpegla.com/main/programs/AVC/Pages/FAQ.aspx
I have a legacy file format that contains sounds embedded in it (in various encodings). I would like to be able to play these sounds in Flash (Air?) by reading the sound bytes out of the file and instantiating a Sound object with them.
If the sound is unencoded (e.g., raw pcm), I've found that I can use the new flex 4 SampleDataEvent.SAMPLE_DATA event to play the sound.
However, if the sound is encoded (e.g., mp3), then I'm at a loss. The sound expected by SampleDataEvent.SAMPLE_DATA has to be raw pcm. From what I've seen, encoded Sounds can only be instantiated by [Embed]ing them, or by using a URLRequest with Sound.load().
Surely there's a third way? AMF or e4x?
There are really only two routes for you to go. The first is to write a decoder in ActionScript. You may be able to use Alchemy to port over some C/C++ code to make this job significantly easier (and possibly more performant). This is exactly how I got Ogg Vorbis playback to work with Flash.
The other option is to dynamically create a valid SWF inside of a ByteArray. That SWF could contain an embedded sound object that was made up of your sound data. A number of folks have pulled off similar hacks in the past before Flash Player 10 was available. I believe you can find a good place to start in Andre Michelle's and Joa Ebert's PopForge codebase.