Я использую JCIFS для доступа к файловому ресурсу с большим количеством японских имен на нем, и я сталкиваюсь с проблемами, когда символ · в нем
Например:
путь 人事部/要員 · コ ス ト 管理 課/
первая часть в порядке, но вторая часть вызывает проблему. Это может быть связано с тем, что "·" можно ввести с помощью косой черты, но Im не уверен. Я попытался убежать от персонажа, но это, похоже, не устраняет проблему. У вас есть какая-то подсказка, что может вызвать это?
Как @sergey-tachenov укажите, что проблема связана с U+30FB (KATAKANA MIDDLE DOT), тогда ее необходимо решить. По этой причине я хотел бы поделиться некоторыми предыдущими проектами и предложениями.
Один из моих проектов, мы делаем несколько руководств для проекта. Руководство было на разных языках. Там у нас такие же проблемы. Мы использовали Lotus Notes. В этом случае мы сделали несколько фильтров, которые изменили эти символы или глифы на точку. После этого примечания лотоса создают папку и имя файла, которые позже используются в качестве пути. Таким образом, эта проблема была решена таким образом. Если у вас есть этот тип опции, вы можете легко исправить.
Различные люди сталкиваются с такими же проблемами. Поэтому они пытались разными способами.
Некоторые говорят,
KATAKANA MIDDLE DOT (・) является символом двойной ширины. Если ты хочешь
используйте центральную точку Katakana (японская), подумайте об использовании HALFWIDTH
KATAKANA MIDDLE DOT вместо этого.Если вы видите twitter-text, они сделали решение для KATAKANA MIDDLE DOT (・). См. В github repo
Проблема Katakana Middle Dot решена в Twitter-тексте
Но разработчик attom chrissimpkins заявил, что ниже
Я могу подтвердить, что у нас нет глифа средней точки Катакана (U + 30FB) в обычном шрифте Hack. Существует средняя точка (U + 00B7), которая будет что вы здесь. Я могу подтвердить, что Символ U + 00B7 имеет тот же фиксированный интервал ширины, что и остальная часть регулярное множество (и все остальные варианты).
Ссылка ресурса: https://github.com/atom/atom/issues/9115
Во-первых, я хочу поделиться с вами, что точка или период (.) символ ASCII. Так что точка (.) Не проблема. Символьная кодировка и Настройка сервера может быть проблемой.
URL-адреса можно отправлять только через Интернет, используя набор символов ASCII. Если URL-адрес содержит символы вне набора ASCII, URL-адрес должен быть преобразован.
smb://[[[domain;]username[:password]@]server[:port]/[[share/[dir/]file]]][?param=value[param2=value2[...]]]
jCIFS также может обращаться к серверам и рабочим группам.
Важно: все URL-адреса SMB, которые представляют рабочие группы, серверы, общие или для каталогов требуется конечная косая черта '/'.
При использовании класса java.net.URL с 'smb://' URL-адресами необходимо сначала вызвать метод static jcifs.Config.registerSmbURLHandler();. Это необходимо для регистрации обработчика протокола SMB.
Компонент userinfo URL-адреса SMB (domain; user: pass) должен быть URL-адресом закодирован, если он содержит зарезервированные символы. Согласно RFC 2396 эти символы не являются символами US-ASCII и большинством метасимволов однако jCIFS будет работать правильно с чем угодно, кроме "@", который используется для исключения компонента userinfo с сервера, а "%" - URL-адрес escape-символа.
Затем вы должны знать, какую кодировку вы используете. Используя следующий код, вы можете получить:
System.out.println(Charset.defaultCharset());
или вы можете дать команду
$ testparm -v | grep dos
показывает, что стандартная OEM-кодировка Samba
CIFS использует либо
UTF-16LE, либо кодовую страницу по умолчанию. По умолчанию кодовая страница, используемая JCIFS, - Cp850 или US_ASCII.
В jCIFS вы можете установить UTF-8 и проверить:
System.setProperty("jcifs.encoding", "UTF8");
Затем для japanese locale вы можете попробовать
System.setProperty("jcifs.encoding", "Shift_JIS");
обмениваться именами, паролями, и в некоторых случаях имена файлов и каталогов, которые содержат не ASCII символы могут не обрабатываться должным образом. По умолчанию это свойство Cp860, которое является MS-DOS Latin1.
Примечание. Преобразователь символов Cp860 находится в jre/lib/charsets.jar который AFAIK поддерживается только интернационализированной версией Sun JRE. Если Cp860 недоступен, произойдет исключение. Избегать это исключение, вы можете установить jcifs.encoding в ASCII, но обмениваться именами и пароли с не-ASCII-символами обрабатываются неправильно. Чтобы определить, правильно ли обрабатывается jCIFS, эти символы создают который содержит символы, отличные от ASCII (например, Grüße), а затем попытайтесь список, который совместно используется с программой ListFiles.java.
Для японского языка вы можете попробовать установить jcifs.encoding = Shift_JIS
В следующих таблицах показаны кодировки Japanese, поддерживаемые J2SE 5.0. Канонические имена, используемые новыми API java.nio, во многих случаях не совпадают с теми, которые используются в API java.io и java.lang.
----------------------------------------------------------------------------------------------
|Canonical Name for | Canonical Name for java.io | Description |
| java.nio API | and java.lang API | |
----------------------------------------------------------------------------------------------
| EUC-JP | EUC_JP | JISX 0201, 0208 and 0212, EUC encoding |
| | | Japanese |
----------------------------------------------------------------------------------------------
| ISO-2022-JP | ISO2022JP | JIS X 0201, 0208, in ISO 2022 form, |
| | | Japanese |
----------------------------------------------------------------------------------------------
| Shift_JIS | SJIS | Shift-JIS, Japanese |
----------------------------------------------------------------------------------------------
| windows-31j | MS932 | Windows Japanese |
----------------------------------------------------------------------------------------------
| x-euc-jp-linux | EUC_JP_LINUX | JISX 0201, 0208, EUC encoding Japanese |
----------------------------------------------------------------------------------------------
| x-eucJP-Open | EUC_JP_Solaris | JISX 0201, 0208, 0212, EUC encoding |
| | | Japanese |
----------------------------------------------------------------------------------------------
| x-IBM33722 | Cp33722 | IBM-eucJP - Japanese (superset of 5050) |
----------------------------------------------------------------------------------------------
| x-IBM930 | Cp930 | Japanese Katakana-Kanji mixed with 4370 |
| | | UDC, superset of 5026 |
----------------------------------------------------------------------------------------------
| x-IBM939 | Cp939 | Japanese Latin Kanji mixed with 4370 |
| | | UDC, superset of 5035 |
----------------------------------------------------------------------------------------------
| x-IBM942 | Cp942 | IBM OS/2 Japanese, superset of Cp932 |
----------------------------------------------------------------------------------------------
| x-IBM943 | Cp943 | IBM OS/2 Japanese, superset of Cp932 |
| | | and Shift-JIS |
----------------------------------------------------------------------------------------------
Я использовал общий пример кода для JCIFS. Вы можете попробовать
import jcifs.smb.*;
jcifs.Config.setProperty( "jcifs.netbios.wins", "192.168.1.220" );
NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication("domain", "username", "password");
SmbFileInputStream in = new SmbFileInputStream("smb://host/c/My Documents/人事部/要員・コスト管理課/somefile.txt", auth);
byte[] b = new byte[8192];
int n;
while(( n = in.read( b )) > 0 ) {
System.out.write( b, 0, n );
}
Вы также можете читать/писать, удалять, создавать каталоги, переименовывать, содержимое списка каталогов, перечислить рабочие группы /ntdomains и серверы в сети, перечислить доли сервера, открыть именованные каналы, проверить подлинность веб-клиентов..etc.
Классы SmbFile, SmbFileInputStream и SmbFileOutputStream аналогично классам File, FileInputStream и FileOutputStream
Используя FileInputStream и FileOutputStream, код будет выглядеть следующим образом:
SmbFile[] files = getSMBListOfFiles(sb, logger, domain, userName, password, sourcePath, sourcePattern);
if (files == null)
return false;
output(sb, logger, " Source file count: " + files.length);
String destFilename;
FileOutputStream fileOutputStream;
InputStream fileInputStream;
byte[] buf;
int len;
for (SmbFile smbFile: files) {
destFilename = destinationPath + smbFile.getName();
output(sb, logger, " copying " + smbFile.getName());
try {
fileOutputStream = new FileOutputStream(destFilename);
fileInputStream = smbFile.getInputStream();
buf = new byte[16 * 1024 * 1024];
while ((len = fileInputStream.read(buf)) > 0) {
fileOutputStream.write(buf, 0, len);
}
fileInputStream.close();
fileOutputStream.close();
} catch (SmbException e) {
OutputHandler.output(sb, logger, "Exception during copyNetworkFilesToLocal stream to output, SMP issue: " + e.getMessage(), e);
e.printStackTrace();
return false;
} catch (FileNotFoundException e) {
OutputHandler.output(sb, logger, "Exception during copyNetworkFilesToLocal stream to output, file not found: " + e.getMessage(), e);
e.printStackTrace();
return false;
} catch (IOException e) {
OutputHandler.output(sb, logger, "Exception during copyNetworkFilesToLocal stream to output, IO problem: " + e.getMessage(), e);
e.printStackTrace();
return false;
} finally {
OutputHandler.output(sb, logger, "Exception during copyNetworkFilesToLocal stream to output, IO problem: " + e.getMessage(), e);
e.printStackTrace();
return false;
}
}
Кредит отправляется @человеку по имени haney
Ссылка ресурса: Как скопировать файл из общего ресурса smb на локальный диск с помощью jcifs в Java?
В большинстве случаев URL-адреса, работающие через HTTP, работают нормально, но не при использовании HTTPS (т.е. через SSL). Обычно это приводит к тому, что символы Unicode (не ASCII) в URL-адресе HTTPS отображаются неверно в URL-адресе, а обслуживаемая страница содержит многочисленные ошибки
Это происходит, когда флаг useBodyEncodingForURI="true" не определен в определении соединения HTTPS в conf/server.xml сервера приложений Apache Tomcat с JIRA. Этот флаг устанавливается как таковой по умолчанию в 'рекомендуется' дистрибутивные установки JIRA.
Однако в настройках JIRA WAR это может быть не так. Следовательно, убедитесь, что флаг useBodyEncodingForURI="true" включен в следующий элемент файла conf/server.xml вашей установки Apache Tomcat под управлением JIRA:
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true" />
После указания useBodyEncodingForURI="true" во всех определениях соединителей (i.e. both the HTTP and the HTTPS connectors), как описано в разделе "Модификация Tomcat server.xml" Установка JIRA на Документация Tomcat 6.0 или 7.0
Как получить символы Unicode 'не-ASCII' в URL-адресе HTTPS для корректного отображения
Взгляните на комментарий heenenee, пройдитесь по файловой системе вашего сервера, чтобы проверить, что такое реальное имя. Я тестировал доступ к сетевым ресурсам со средней точкой и японскими именами на сервере Samba (UTF-8) с источником Java (UTF-8) без проблем.
import java.io.File;
import java.io.IOException;
import java.nio.charset.Charset;
import org.apache.commons.io.FileUtils;
import org.apache.commons.io.IOUtils;
import org.junit.Test;
import jcifs.smb.SmbFile;
import junit.framework.TestCase;
public class JCifstest extends TestCase {
@Test
public void testJCifs() throws IOException {
System.out.println(Charset.defaultCharset());
SmbFile smbFile = new SmbFile("smb://myuser:[email protected]/basepath/人事部要員・コスト管理課/test.txt");
File destFile = new File("/tmp/" + smbFile.getName());
FileUtils.writeByteArrayToFile(destFile, IOUtils.toByteArray(smbFile.getInputStream()));
assertEquals("content", FileUtils.readFileToString(destFile));
}
}