Take a look at the WebServer setting in the portal at Configuration > Additional Settings > Startup:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

This changes the WebServer entry in the [Startup] section of cache.cpf.

I notice two things:

1. The C# ciphertext is 64 bytes, which is twice as long as I'd expect for a 31-byte input.
2. In the first sixteen bytes of the C# ciphertext, alternating bytes are NUL.

I thought maybe C# is using UTF-16, but I I haven't managed to replicate its output using $zconvert with "UnicodeLittle" or "UnicodeBig".

Edit: the first sixteen bytes of the output appear to be the first eight bytes of the initialization vector converted to Base-64, then UTF-16.

For the most part, dynamic objects use local memory that is accounted for by $zstorage and $storage. However, some of it comes from other heap-allocated memory, similar to long strings. You can round trip a large JSON object through a dynamic object with %FromJSON()/%ToJSON(), even if an individual field exceeds the string limit. However, it is not currently possible to get the value of such a field within Caché.

Note that you should call %ToJSON() such that it outputs to a device or writes to a stream:

USER>d o.%ToJSON(stream)

USER>d o.%ToJSON()

Otherwise, you may get a STRINGSTACK error:

USER>w o.%ToJSON()

W o.%ToJSON()
^
<STRINGSTACK>

Are you sure that this problem is due to endian? A byte stream does not in itself have a byte order; multi-byte data structures do, such as Unicode characters encoded as UTF-16. As for the signature itself, I would expect its encoding to be specified in a portable manner.

Is it possible that line endings are getting changed?

This method probably first shipped with Caché 4.0 in December 2000, but the oldest instance I have handy is Caché 4.0.4:

USER>w $system.Version.GetMajor()
4

I don't really understand the question. It sounds like you're trying to convert from one eight-bit character set to another, but French generally uses the same character set as English, as far as I know. If you're using a Unicode instance of Caché, your first resort should be I/O translation: translate the input to Unicode, then translate on output to the desired character set. Doing it in COS is slower and less convenient.

That said, here are some things in your code that don't really make sense:

1. a."i"; should probably be a.%Get(i).
2. a-128; maybe a.%Get(c-128)?
3. I don't understand the purpose of the first loop or the return statements.
4. value(j); ...?

If I were to hazard a guess at rewriting this, my first try might be something like this:

for i=1:1:$l(str) {
    s c=$e(str,i)
    if $a(c)<128) {
        w c
    } else {
        w $c(a.%Get($a(c)-128))
    }
}

I can't reproduce this in a 2016.2 instance I have handy:

USER>s filename="DKA0:[QD.CACHEJCWG2.MGR.USER]CACHE.DAT"

USER>w $zf("GETFILE",filename,"UIC")                    
[1,1]

Can you get the output of $zu(56,2) after the error? Anything unusual about your filename?