UTF-8 encoded MS Access table - ms-access

I have a MS Access table which is encoded in UTF-8 charset and the characters appear like this:
Participació en comissió
If I UTF-8 decode this text I get the correct text:
Participació en comissió
How can I utf-8 decode several Access table columns? I would like to end up with the same MS Access database but with the columns converted (utf-8 decoded). I cannot figure out an easy way to do this conversion.
Thanks in advance.
--
More clarifications:
So how did you decode the text that you have in the question?
I simply put the sentence in an online utf-8 decoder but it crashes when there is a lot of text. FYI, the Access table comes from a MS SQL Server database with Modern_Spanish_CI_AS collation and varchar (MAX) data type field. Maybe is there a way to perform the conversion while exporting the table from the MS SQL Server?

While searching for a solution I found this post that has a function to decode utf-8 fields right from the MS SQL Server. I tested it and it works perfectly, althought it is quite slow. Hope this helps someone else with the same problem.
New query editor and copy&paste the function provided in this link:
Convert text value in SQL Server from UTF8 to ISO 8859-1

Related

How to export text data with Hebrew and special characters from SAS to ACCESS?

I have a SAS table that contains hundreds of thousands of rows and several text fields and I need to import this table into and ACCESS database.
The fields contains names in Hebrew characters and special characters such as commas, colons, brackets, quotes, double quotes and any other character you can think of.
I've tried exporting the table as a CSV file and importing it into my ACCESS database and encountered 2 issues:
Access does not recognize the Hebrew characters
Every time there is a special character that is also defined as a delimiter in the access import query, the data is read incorrectly.
Any ideas?
Im using SAS 9.2 and ACCESS 2010 on Windows XP. I'll probably be upgrading to Windows 7 and SAS 9.4 soon so I can have integrated connectivity between ACCESS and SAS. Anyone knows if it solves those problems?
Thanks.
Okay folks, i found the answer, and its really simple.
Instead of exporting to a CSV file and then to Access, there is an option of exporting data directly from SAS to an Access database (somehow I missed it before...).
Seems to work well. It keeps the Hebrew characters and doesn't mess the data. The SAS table and the ACCESS table are not linked, but that's not an issue in my current application.
Code used:
`
PROC EXPORT DATA=lib.table
OUTTABLE= "table1"
DBMS=ACCESS REPLACE;
DATABASE= "L:\test.accdb";
RUN;
`

MySQL Exporting Arabic/Persian Characters

I'm new to MySQL and i'm working on it through phpMyAdmin.
My problem is that i have imported some tables with (.sql) extension into a database with: UTF8_general_ci format and it contains some Arabic or Persian characters. However, when i export these data into an Excel file, they appear as the following:
The original value: أحمد الكمالي
The exported value: أحمد  الكمالي
I have searched and looked for this issue and tried to solve it by making the output and the server connection with the same format UTF8_general_ci. But, for some reason which i don't know, the phpMyAdmin doesn't allow me to change to the same format, it forces me to chose this: UTF8mb4_general_ci
Anyway, when i export the data, i'm making sure that the format is in UTF8 but it still appears like that.
How can i solve it or fix it?
Note: Here are some screenshots if you want to check organized by numbers.
http://www.megafileupload.com/rbt5/Screenshots.rar
I found easier way that you can rebuild excel file with correct characters.
Export your data from MySQL normally in CSV format.
Open new Excel and go to Data tab.
Select "From Text".if you not find this it is under "Get External Data".
Select your file.
Change file origin to Unicode(UTF-8) and select next.("Delimited" checked by default)
Select Comma delimiter and press finish.
you will see your language characters correctly.See more
Mojibake. Probably...
The bytes you have in the client are correctly encoded in utf8mb4 (good).
You connected with SET NAMES latin1 (or set_charset('latin1') or ...), probably by default. (It should have been utf8mb4.)
The column in the tables may or may not have been CHARACTER SET utf8mb4, but it should have been that.
(utf8 and utf8mb4 work equally well for Arabic/Persian.)
Please provide more details if this explanation does not suffice.

Garbled special characters with SQL rendering of XML data

I have a DHTMLX grid on a page that saves data through a php connector file to a DB. The data from the grid is shown through xml encoding that is rendered in the PHP connector file.
Japanese words in the grid show up in Japanese but get saved as: ーダー
However they do stay in Japanese in the grid! (somehow...)
If I save something in the DB on php myadmin, it shows up in the grid as: ???
I checked and everything seems right...
DB fields: UTF-8 √
HTML headers: UTF-8 √
connector.php: UTF-8 √ (checked through network tab, devtools)
Is there anywhere else I should check?
When looking at the PHP file that gives me the DB values, I get XML data that's already garbled:
<rows><row id='00000000001'><cell><![CDATA[]]></cell><cell><![CDATA[??]]></cell><cell><![CDATA[33]]></cell><cell><![CDATA[]]></cell><cell><![CDATA[]]></cell><cell><![CDATA[?????????]]></cell>...
So maybe the problem lies before the data is received from the server. Does anyone know where I should look for the problem?
Were you expecting ーダー for ーダー? (Mojibake.)
Other times, do you get question marks?
Those two symptoms come from different causes. But both usually involve not declaring the client bytes to be utf8. In php, that can be done with mysqli_set_charset('utf8')
Question marks usually also involves failing to declare the column to be utf8.
To further diagnose, please do
SELECT col, HEX(col) FROM tbl WHERE ...
so we can see whether the text was mangled as it was inserted.

SSIS Convert english BlobColumn to String ending up with Chinese characters

I am transferring data from MS SQL to MYSQL. The transfer works, but having trouble with BlobColumn. I am achieving the transfer using a script component, and coding the insert statement. I have several blob columns that are 'text' columns in MySQL. I am converting like this:
Replace(System.Text.Encoding.Unicode.GetString(Row.link_desc.GetBlobData(0, Convert.ToInt32(Row.link_desc.Length))), "'","\'")
It transfers the contents, but they are in Chinese characters after the transfer. I assume this has something to do with the Encoding, but not sure what.
Sounds to me like the data coming in may be ASCII and your encoding is Unicode. Try:
Replace(System.Text.Encoding.ASCII.GetString(Row.link_desc.GetBlobData(0, Convert.ToInt32(Row.link_desc.Length))), "'","\'")

Problem with charset

I have an MYSQL Database in utf-8 format, but the Characters inside the Database are ISO-8859-1 (ISO-8859-1 Strings are stored in utf-8). I've tried with recode, but it only converted e.g. ü to ü). Does anybody out there has an solution??
If you tried to store ISO-8859-1 characters in the a database which is set to UTF-8 you just managed to corrupt your "special characters" -- as MySQL would retrieve the bytes from the database and try to assemble them as UTF-8 rather than ISO-8859-1. The only way to read the data correctly is to use a script which does something like:
ResultSet rs = ...
byte[] b = rs.getBytes( COLUMN_NAME );
String s = new String( b, "ISO-8859-1" );
This would ensure you get the bytes (which came from a ISO-8859-1 string from what you said) and then you can assemble them back to ISO-8859-1 string.
The other problem as well -- what do you use to "view" the strings in the database -- is it not the case that your console doesn't have the right charset to display those characters rather than the characters being stored wrongly?
NOTE: Updated the above after the last comment
I just went through this. The biggest part of my solution was exporting the database to .csv and Find / Replace the characters in question. The character at issue may look like a space, but copy it directly from the cell as your Find parameter.
Once this is done - and missing this is what took me all morning:
Save the file as CSV ( MS-DOS )
Excellent post on the issue
Source of MS-DOS idea