I am trying to open a .log file while in Sublime Text 3 (v3.2.2, Build: 3211) installed on Mac OS Catalina and I see that it opens with plain hex numbers.
This is a small snippet:
205b 6465 6275 675d 2031 3631 3736 2330
3a20 6570 6f6c 6c20 7469 6d65 723a 202d
I am not sure why this happens but I am not able to see any quick link for the same anywhere for this issue.
This is an indication that Sublime thinks that the file that you tried to open is a binary file; it's controlled by this setting (which as seen here defaults to true):
// Files containing null bytes are opened as hexadecimal by default
"enable_hexadecimal_encoding": true,
When this is turned on, the file is opened using the Hexadecimal encoding as a warning to you that the file is (or seems to be) a binary file. If the file is actually binary, then you probably don't want to be editing it with a text editor.
On the flip side, if the file is actually a text file with something in it that makes it detect as binary, then it's possible that the detection of what encoding the file is actually using may not work the way you expect, which can cause other issues. So in that case the setting opens the file in Hexadecimal as a warning to you that you need to tell Sublime what encoding it should be using.
If you're sure the file is actually a text file (probably a good guess for a .log file), then you can use File > Reopen with encoding to tell Sublime that it should be using a different encoding, for example utf-8. You can also try turning off the above setting so that this doesn't happen, although in that case as mentioned the encoding that's selected may be incorrect.
Related to this, there's another setting that can come in handy:
// Display file encoding in the status bar
"show_encoding": false,
This one defaults to false, but when you turn it on the encoding of the current file appears in the status bar on the right hand side, near where you see the indent settings and the type of the current file.
If this is turned on, you can easily verify exactly what encoding is currently being used, and you can also click there to get a menu that lets you change the encoding of the current file or quickly re-open it using a different encoding.
Related
By default MacOS's built in QuickLook feature displays only latin characters + figures when previewing font files. This is what it looks like:
typical QuickLook preview window for a font file
I need to be able to quickly see if the font contains non-latin characters, for example Cyrillic. I am sure there is a way to edit some .plist file inside macOS to modify the list of characters that QuickLook shows for a font in order to add some non latin characters. I even did it once, but it was a few releases of MacOS ago, when System and Library folders were not hidden and thus were searchable.
Could someone please advise, where this .plist file may be located now in MacOS (HighSierra)? Thanks!
Found a solution myself:
The various character sets that QuickLook presents are based on the language which is the primary language you are using. The character sets are are kept in a file called SampleSupport.plist which is found at:
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/Resources
Copy this path and in Finder go: Command + Shift + G and paste the path into the field and you will instantly brought to the right place.
Edit the file in your favourite editor. Edit the EN char string to add some non-latin chars.
editing SampleSupport.plist to show non-latin characters
I am trying to create a test csv file for a file cleaning script that is supposed to normalize all whitespace into "normal"/ "regular" whitespace character. The idea is I will insert a bunch of these oddball whitespace characters into this test file in some various locations.
Here are some sites that show these various and oddball whitespaces
https://en.wikipedia.org/wiki/Whitespace_character
http://jkorpela.fi/chars/spaces.html
I've tried to copy and paste from sources like that website but it seems like they always paste in as a normal space in Textmate. It could be that I am not copying what I think I am copying. In the past I've been able to copy and paste into Textmate special / unicode characters when I can clearly see what I am copying but with whitespace characters, I can't confirm since I can can't see it, so I am not sure if the problem is where I am copying from or that Textmate is converting it to the normal space when I paste it in.
If it is easier to use Textedit (the built in editor) or nano (command line editor) to do this I could use those. Or if there is another way other than copying and pasting that is better to get these into Textmate that would be an option.
I am on a MacbookPro running High Sierra MacOS.
If you have LibreOffice installed you can use the spreadsheet application to create these using their hexidecimal equivalent in 1 cell then doing a conversion using
=unichar(hex2dec(cell_ref_to_1rst_cell)).
Far less confusing and you can save the spreadsheet complete with comments as a handy reference. Then you should just be able to copy paste the cell with the unicode character when required.
If you’re using TextMate, various functions provided by the Unicode bundle could be helpful here (install via Preferences → Bundles → Unicode).
With this bundle installed you can use Insert Unicode Character ⌃⌥⌘I to insert a character by name. Search for “space” to get a list of all space characters, then simply click on the desired character (the full title of a character is shown on hover):
Of course once inserted all the space characters look almost identical. To identify them, use Show Unicode Name(s) ⌃⌥⌘U 6. This will display a tooltip showing the unicode of name of the character directly before the cursor (or the names of all selected characters, if a selection is active).
Also have a look at Show Character Inventory (press ⌃⌥⌘U and then select the command from the popup menu): This provides a convenient overview of all the characters in your document (or in the selected text, if a selection is active).
Examining some files (log files, *.ldb files which are backups created by a chrome extension and so on) I find that some of those files are seen OK by Mac's QuickLook:
But sublime open them like this:
Explanations? Fixes?
In ST3's default preferences is the following:
// Files containing null bytes are opened as hexadecimal by default
"enable_hexadecimal_encoding": true,
so I guess your ldb files contain null bytes. Simply set this to false in your user preferences, and ST should try to display the file as text.
I used vim to open a file event.txt and show me some search results. This worked fine, but since I did a change in the _vimrc it displays the file content with #-signs so that it is unreadable. See image below.
What I did change in _vimrc was
set fileencoding=utf-8
but I commented it. So it should not affect vim.
"set fileencoding=utf-8
The file is still displayed unreadable. With other editors I can open the file and view it normally. I had this behaviour some time ago, but I vanished somehow. I can't remember.
The event.txt file is the windows event file which I generate through the powershell:
get-eventlog -logname system > event.txt
Something tells me it's not the change in the _vimrc and perhaps something else, but this is the last change I remeber I did and after this it did not work.
How can I view in vim the windows event file event.txt normaly? Without #-signs.
That ÿþ at the beginning is a byte order mark (BOM), typical for Windows Unicode text. The ^# is Vim's representation of a NUL value, and it (roughly) appears as every second character. So, you have a (mostly) ASCII-text file, encoded in UCS-2 little endian: each character is represented by two bytes (16 bit), the lower one comes first.
You can open that file with
:edit ++enc=ucs2-le event.txt
But it's better to set up Vim correctly so that it automatically detects it. Since you're using GVIM on Windows, I would recommend to put
:set encoding=utf-8
at the start of your ~/.vimrc. This will automatically set your 'fileencodings' to a good default of ucs-bom,utf-8,default,latin1. Note the first element; that should help detect the file.
Do not set 'fileencoding' in your ~/.vimrc! That is a buffer-local setting, and it will be automatically set by Vim on opening of the file. The 'fileencodings' (note the plural) is the right option to influence the detection.
In the Open with menu of a .cs file there's Csharp editor and Csharp editor with encoding. I opened a solution with both and didn't see a difference.
What's the difference between them?
Unless your .cs file includes characters outside of the normal ASCII range, you won't see a difference in the actual contents of the file. The difference is whether or not the editor tries to detect the character encoding you saved your file with when you open it again, or asks you specifically.
By default, when you save a new .cs file, VS uses the current ANSI code page to encode the characters. (You can switch this to use UTF-8 by default with the appropriate options.) However, you can instead chose to "Save with Encoding...", which will prompt you for the specific character encoding you want to save it.
Internally, your code is being handled as UTF-16, since that's what Windows deals with as it's native string format. On-disk, however, UTF-16 would most likely blow up your source files to double their size, since most of the C# code you write probably fits into a single byte. So, when writing to disk, VS writes out your data in a particular code page that defines how to convert the UTF-16 characters into some other, possibly 8-bit character set.
When you reload a file in VS, it attempts to figure out what encoding that file was in, and if it can't, it will fall back on the current ANSI code page. (You can force it to fall back to UTF-8 via some options, but it won't ever fall back to a different encoding.)
When you reload a file "With Encoding", you get the same prompt as when you saved the file, asking you which encoding was used. This way, if Studio gets it wrong, you can fix it.
Unless you do a lot of internationalized programming, where you have foreign-language strings embedded in your .cs file from a language other than the default, you probably don't need to use the explicit "with encoding" save or loads. But, they are there if you need them.
If you open with encoding you can save with whatever character encoding is appropriate for your culture or region.