I have few lines in a file that's been loaded into list. In the file is line that starts with EKO-1223... I would like to get this line, so I am using a while loop and iterate over the lines from the list. I am using nPos = StrFind(svLine, "EKO") but the nPos is < 0 so it does not find the result, why?
If you want a good answer, you'll need to provide more details on how you get the text from the file into svLine, as well as anything you know about the file's encoding, etc. (If you know nothing about encodings, a hex dump of the first few bytes of the file, as well as those including the EKO- may suffice to identify it.)
My guess is either you haven't properly loaded svLine at all, or that the encoding was misidentified, and thus svLine contains something like "E\0K\0O\0..." or "䭅ⵏ" (that is "\x4b45\x2d4f" in C notation). Can you confirm with a message box or in the debugger?
One alternative you could consider is calling FileGrep. This could help if your code didn't load the file at all, but is unlikely to handle encodings any better. If it's improperly detected encoding and you can change the file, ensure the file has the correct BOM for its encoding. But if you don't control the file, I'm not sure what to recommend. Binary reads and manual decoding (possibly leveraging Kernel32.MultiByteToWideChar) might be your best bet.
Related
I have a .c file that I want to open with python 3 to update a specific number on a specific line.
It seems like the most common way to do this would be to read the file in, write each line to a temporary file, when I get to the line I want, modify it, then write it to the temp file and keep going. Once I'm done, write the contents of the temp file back to the original file.
The problem that I have, is that in the comments of the file there are Japanese characters. I know I can still read it in by adding the error equal ignore argument, that allows me to still read the lines in but it gets rid of the Japanese characters completely and I need to preserve those.
I haven't been able to find a way how to do this. Is there any way to read in a file that's part in Japanese and part in English?
I am looking for a way to convert or save a text file in the UCS-2 LE format; specifically without BOM...i guess.
I have zero knowledge what any of that means actually; but i know i need that because of this wiki page on what i am trying to accomplish: https://developer.valvesoftware.com/wiki/Closed_Captions
in other words:
this is for a specific game engine, "Source Engine," which requires the format in order to compile in-game closed captions for sounds.
I have tried saving the file in Notepad++ using the "UCS-2 LE BOM" option under the encoding menu...there is no option for just "UCS-2 LE" however, and because of this, the captions cannot be compiled for the game engine. I need to save without BOM, "I guess" (because again I don't know what I'm talking about and I assume based on logical conclusions, that I need to not have BOM, whatever that actually means.)
I would like to know about a way to either save a txt file in that encoding format; or a way to convert one.
In my specific case; it appears that my problem boils down to "the program is weird."
what I mean by this is, notepad++ actually does save in the correct format; but I failed to realize that because of a quirk in the caption compiler where it only works if you drag the file onto it; not via command line as previously thought.
I will accept this as the answer when i am allowed to in 2 days.
I am using Node.js to write to log files, using the colors module which I believe inserts control characters into strings, for coloring/text formatting which will display in a terminal application.
When I write to the terminal directly, it shows colors, but when I write to a .log file and then tail the log file with either Terminal.app or iterm2, it does not show colors/text formatting. Does anybody know why this is? My guess is that when you write to the log file the control characters don't get saved? In that way, when tailing they won't display at all?
Perhaps if I write to .txt file or some other type of file, the control characters will remain?
How does this work exactly? At some point the control characters are getting stripped or ignored and I am not sure how or when.
See this code.
It checks if the output is going to a terminal (by checking process.stdout.isTTY) or to somewhere else, like a file. If the latter, no color codes are outputted.
I have about 3,500 text files, of mixed character sets: ISO-8859, UTF-8, ASCII, UTF-16, and maybe others.
I want to merge them all into one unicode text file, so I can run a Python script on it that expects it.
If I use cat, it doesn't exactly work.
What is the best way to solve this?
You could convert them up-front with a tool like iconv, or load them into Python with the correct encoding (by setting the correct encoding to open).
If you don't know what the encoding of each file is, then it is more complicated, because you'll need to detect the encoding of each file. There are many heuristics, but not absolutely standard way to do this. Again, using iconv can help a lot here.
I need to insert a generated file into an exe at the time of download. Currently, I create an "empty" file (filled with a repeating character) and package that with the exe. When it comes time to download, I look at the bytes for the installer, find the file by looking for the repeating character, and insert the generated file.
This process however is not working. The repeating character just does not show in the bytes. But I am certain the file is there as it is unpacked if I run the exe. Am I doing something wrong or is inserting a file into an exe even possible?
Also note that I am using Inno Setup Script v5.5.1 to compile the project into an exe.
If you want to change the contents of a file specified in a [Files] entry and compiled into the setup executable, then you must:
Make a dummy file that is at least as large as the largest content you will want to insert.
Fill the file (or at least the first 64 bytes or so) with something unique and easily distinguishable.
Mark its [Files] entry with the "nocompression noencryption dontverifychecksum" flags.
You should then be able to scan the resulting executable for the marker in #2 and then substitute the data that you want. Note however that doing this might invalidate any digital signature on the setup file, although I haven't tested this to be sure.
Note that if the content you are inserting is smaller than the dummy file size, the extra bytes will still remain on the end of your inserted content. So whatever reads the file will have to have some way to ignore that or to recognise the end of the interesting content.
So, if your are making changes in the existing exe file, and if the text is not much, you can probably use some hex editor and make changes at desired location. If text is more , you might want to include some meaningless bytes, just as fillers.