Preliminary information about Unicode support (TC7.5)

[milo1012]

2ghisler
The current download link is
http://www.oracle.com/technetwork/middleware/content-management/downloads/oit-dl-otn-097435.html

You need to download the Content Access packages for Windows (x86-64)
and copy all files from the "redist" dir to the subdir "oit64" of the PCREsearch plugin.
You need the Visual C++ Redistributable Packages for Visual Studio 2013 for making the filter work.

But like I said, the APK-wdx plug-in uses the very same procedure to output the Unicode stream and therefore shows the same behavior.
So it's probably enough to test only one plug-in.


I really don't know what else I should do to convince you that this is an actual x64 bug, because the very same code works flawless for 32-bit.
I explained above that this is triggered by certain strings with spaces in them, while "single word" strings seem to work fine.
This fact alone shows clearly that the bug is not on my side, cause I return the same data for any search, i.e. the search itself lies in your own code.
On top of that: doing a simple MessageBox() on the output was enough to confirm that I stream the correct data.
I don't know why your own plugins do not trigger the behavior, but you can at least try to confirm that there is something wrong in x64 when using my setup and verify that you received the correct data.
(and my guess so far: it's triggered by a certain string length that I return)

[ghisler(Author)]

Thanks for the download links, I will test it.

[milo1012]

The bug is finally fixed in beta 6.

17.07.16 Fixed: Content plugin, full unicode text field, text search: Results wrong in 64-bit due to wrong buffer size reported to plugins (64)

I think it could have been solved way earlier if you'd answered my former question(s) about maxlen.
Anyway, I'm glad that it's finally working.

[ghisler(Author)]

Sorry, I thought that I had fixed it, but the fix was only applied to the 32-bit version. It didn't show up in the PDF search plugin because this plugin only returns small blocks of text at a time (a few 100 characters max), so it never hit the limit...